How many sites do you visit that are full of indecipherable jargon? Littered with cringe worthy stock images, confusing layouts, and slow to load? Beautiful but functionally flawed. How many of the sites you’ve built are like that? Own up – we’ve all done it… (although hopefully not ticking all those boxes at once!)

We’re all part of the problem – we’ve lost sight of the purpose of the sites we build. It’s all about users, not us; we are definitely not “average users”.

---

---

The problem

Accessibility is often an afterthought, maybe a token aria-role and not much more. But accessibility effects us all and permeates every aspect of a website. Accessibility isn’t about disability. That’s not to say that you shouldn’t be making your site accessible to the disabled, but accessibility is about everyone.

Every decision we make about development, design and content effects whether people can understand and use your site. Unfortunately many common practices are hampering our users. It’s not hard. It’s just thoughtlessness, and it’s affecting your bottom line.

Here’s a few of the common problems:

Design

Undeniably the low hanging fruit – we’ve all seen, or heard of, designs that are beautiful but frustrating, or even impossible, to use. Pick any trend in web design and there are myriad bad implementations that hinder users:

• Big images (full screen background images, sliders, “hero” images etc) – without careful implementation these often cause bloated page sizes that drive away limited bandwidth users and can also create artificial “folds” that can confuse people into thinking there isn’t any other content on a page. Worse still, when these images aren’t appropriate and conveying meaning, they can stop users from even being able to tell what your site is about.
• Undifferentiated links – there’s a reason browsers without exception all style links in blue and underlined, it’s the standard. Users are smart: change that shade of blue, fine; change the colour completely to one that stands out from normal text, normally OK; drop the underline, fine; but while changing the colour to be the same as normal text and omitting the underline looks much less “messy”, now no-one has any idea what to click on… The same goes for buttons – “ghost buttons” with no border or background to differentiate them are a bit of a fad lately. I’ve watched too many user-testing videos of people blindly clicking on any object and text as they have no indicator to tell them what is a link / button and what isn’t.

But more problematic are the widely accepted design patterns that fundamentally exclude users:

• “Hamburger” menus (especially on desktop) – yes we all know what they are, but have you actually thought about the rest of your users? Older and less technologically inclined ones in particular are still completely stumped by sites with ‘missing’ menus. “Lots of sites use them” is not a valid response… Lots of sites are also driving away potential users.
• No home button – like the hamburger menu, omitting a home link in the menu is normally justified because “everyone knows you just click on the logo”. But what is really being said is ‘we in the web industry all know to click on the logo and so do the web savvy users’, but what about the rest? Would you really build a hotel with no signs to reception because ‘everyone knows it’s near the dining room’?

Code

Code has its biggest effect on accessibility by affecting the usability of assistive technologies.

You’re doing it wrong if:

• You can’t understand your site when viewing it in outline mode (without styles and images). NB – unfortunately this got more complicated recently with the admission in the HTML5.1 spec that browser support for the document outline model in HTML5 hasn’t appeared.
• You can’t perform basic navigation of your site using just the keyboard. This is critical for everyone from power-users to those with extreme physical disabilities whose assistive technologies normally mimic simple keyboard commands. Strongly tied to this is a design point – removing :focus and :active styling is a really bad idea and leads to keyboard users getting lost on the page.

Content

This isn’t complex in theory, write clear and concise text and you’re done. If you’ve got images or other media then insert them at appropriate points in the flow of text to give them implicit meaning, and ensure that they are relevant and adding meaning / value themselves.

I’ll leave aside the strange desire some companies have for making their website a copy of corporate documents; even if your audience is one coming to view (for example) legal documents, they wouldn’t expect your ‘About’ page to read like one.

But in practice this is more complex than it at first seems. Users abilities fall into a range of categories (including but not limited to):

• Specialists with knowledge of industry specific terminology (jargon to the rest of us).
• Educated general public – this can be educated in the sense of general education / intelligence level, and / or those slightly informed about a specific topic.
• Novices – those with no prior knowledge of a subject, yet who have a reason to access it (even if it is only curiosity).
• Those in any other category where their ability to access the content is physically impaired, for example a level of visual impairment.
• Those in any other category where their ability to access the content is mentally impaired, for example someone with dementia who has trouble holding large amounts of information in their working memory.
• Those in any other category who have a primary language other than the one the content is written in.

Writing while meeting the needs of all these groups is no easy task. Even a sentence as simple as “watch out for trouble” hides problems. Metaphors, idioms, phrasal verbs (there’s a good article on the problems with these specifically on GOV.UK) and other literary devices can all cause problems for users. While they may sometimes be the most appropriate way to phrase something, you should be aware of them and the problems they can cause. Imagine someone reading that example sentence literally…

Personally I find this by far the hardest section. A near final draft of this post scored a distinctly average 10 on Hemingway and a 54.3 for Flesch-Kincaid Reading Ease on Readability-Score.

The beginning of a solution

Rant over. So how do we make our sites inclusive and accessible? There’s no magic bullet, and every site is different and will need tailoring to it’s own audience.

Actions

However this list is a good starting point. In fact if you can follow most of these, you will make a big difference and help keep the web accessible to everyone.

Make it Perceivable

• Give links and buttons clear visual differentiation. Conforming to traditional patterns unless there is a strong reason not to.
• All link states should have clear styling including :focus and :active.
• Link and button text should always explain what it does when read out of context. Use screen-reader only content if absolutely necessary.
• Buttons must be large enough for users on touch devices.
• Colour should never be the only differentiator between two states / meanings.
• Text contrast must conform to AA WCAG2.0 guidelines, always attempt to reach AAA level.
• Avoid overlaying text on images or backgrounds that affect readability.
• Provide text alternatives for non-text content.
• Use semantic code to convey the structure and relationships of content sections. Structure must remain meaningful when viewed without stylesheets and javascript, and also when read by screen-readers.
• Always give inputs labels even if using placeholder text. They can be visually hidden if desired.
• Never disable browser zooming and use relative units for text sizing.

Make it Operable

• You must be able to navigate the site with only a keyboard.
• Focus should not move / be moved unexpectedly.
• Provide ‘skip links’. At a minimum give a ‘skip to content’ link as the first item on the page.
• Provide clear site navigation that is not hidden behind “hamburger” menus.
• Include the homepage in the main navigation.
• Use breadcrumbs to provide navigation at depth.

Make it Understandable

• Always set the lang attribute on the page’s <html> element.
• On your homepage <h1> should be the site title (it can be visually hidden). On all other pages it must be the page / content title.
• Use regular semantic headings to keep content easily digestible and signposted.
• Content and purpose should be clear and as concise.
• Only use images and other media to add value and meaning to the text content. They must appear in an appropriate place so that it is clear what they relate to.
• Keep content related to actions immediately next to each other, both visually and in the code.
• Ensure there is a clear flow of content without unrelated
• Avoid jargon where possible.
• Use metaphors, idioms, phrasal verbs and sayings only when they are truly the most appropriate way to convey your meaning.
• Abbreviations and acronyms should be avoided or have definitions available at every use.

I’ll leave you with this:

The goal, she stated, is a world where all apps are accessible, even in cases where it may seem unintuitive. As an example, she recited her experience in traveling to China and discovering an unknown object in her hotel room that appeared to be a fruit. Rather than sampling it, she took a photo of it and sent it to a friend, who identified the object as being a dragonfruit.

Girma noted she was only able to do that because the Camera app is accessible via Voice Over. Without considering such a scenario, one might imagine that a blind person wouldn’t need an accessible camera app because ‘why would a blind person take pictures?’

Haben Girma at WWDC16, via AppleInsider

---

Further reading:

• Rian Rietveld on semantic and accessible headings
• Improving UX for colour blind users
• Why and how to avoid hamburger menus
• wd_s goes vegetarian
• Mobile accessibility
• Designing dementia friendly websites
• WGAC2.0 Guidelines