I’ve been asked again and again over the years what the absolute basics of web accessibility are. And while I always thought that it is not so difficult to find resources about these basics, the recurrence of that question prompted me to finally write my own take on this topic. So here it is, my list of absolute web accessibility basics every web developer should know about.
One of the questions I get asked the most is “which graphics require alternative text”? The answer to this question has three parts:
All the above also applies to SVG graphics. And if you’re really modern and use the picture element, the rules apply there, too.
Using proper alternative text does not just help blind and low vision screen reader users. It also helps on mobile where images sometimes cannot be loaded, for example over slow connections. So by implementing proper alternative text, you help many more people than you might initially imagine.
Another very common question I get, and a very common error I see on many many web pages even in 2015, concerns the labeling of forms and form fields. In fact, when dealing with many web developers, I am surprised that many don’t even seem to be aware that there is a label element, for example. So here are the most common rules about form field accessibility:
If you need something a little more fancy-looking, please do not fall back to using clickable span and div elements. Because if you do that, you’ll have to add roles, state handling, keyboard focusability and acting on key presses all by yourself. If you use form elements and help yourself with some span elements for styling inside the label, for example, you will get all the accessibility for free, including keyboard, screen readers etc.
Believe it or not, but at its core, the web is a document-based structure. So even when we create fancy web applications such as Gmail, the heart of it is a document. And there is a lot you can do with documents semantically that will get you usually 80 to 90 percent of the accessibility for free. For example:
Noticed the different headings and sub headings in this blog post? Well, there are elements for that. They are called heading elements. And they give you exactly that, a six level heading structure to denote a main heading, secondary sub headings, and sub headings to those for sub sections, like this one, for example. This gives your document a logical, easy to follow structure. Have you ever wondered how Wikipedia puts together its table of contents for each article? They use the logical heading structure for that, too!The h1 through h6 elements are unambiguous in telling screen readers, search engines and other technologies what the structure of your document is. Do not mix unless the structure requires it, do not skip levels if possible, since that will disrupt the logic. And never ever again use something like a div with a class of “heading1” in your code. Screen readers, search engines, and other technologies will not know what to do with those. They will know how to treat your headings properly, though!
There are some more ways to structure your document’s contents. By landmarks, for example. Landmarks can be article, aside, footer, header, nav and main. Adding such landmarks appropriately can help further provide sense to your document and help users more easily navigate it.
HTML knows a whole bunch about lists. There are unordered and ordered lists that are exactly what you’d expect them to be. You can add numbering schemes, even nest them, and the browser will do the rest for you. You can style them the way you want them to look in CSS and thus provide even more structure and meaning to your document’s content. You’ve already seen ordered (numbered) lists in this blog post.
There is also a list type for definition term and explanation groups. The MDN page on the dl element has some great examples of use.
Did you know that HTML has an element to denote paragraphs? It is called the p element. For long citations that require their own paragraphs, use blockquote. For short, inline, quotes, use the q element. Visual separators can be inserted via the hr element.
For all these elements, use CSS to define indentation, separation between paragraphs etc. Those will not impact the semantics, but you are then free to adjust the visuals to your liking or your client’s requirements.
Tables are its own special case. So much can go wrong, and historically, so much abuse has happened to this poor table element and its sub elements! Especially layouts were done for a long time using tables, before HTML 4 and the onset of CSS. But I still find in modern web applications in 2015, cases where layout tables are being used to align form fields and their labels to one another. STOP DOING THAT! PLEASE!
The table element is a very useful element for creating data representations. Product detail listings, price lists etc. Also, shopping carts with quantities, sub totals and totals, and many other structured data collections can, and should, be put into data tables. Here are some tips to help you:
For more information, I’d like to refer you to the friends at WebAIM who have put together a very good two-pager on the accessibility of HTML tables.
HTML defines your content structure. It is what screen readers and other assistive technologies use to represent your content to their users.
CSS defines how that content looks visually. Its positioning, indentation, padding, margins usually have no bearing on what screen readers render to the user, with one exception: If display: none; or visibility: hidden; styles are used, that content will also not be available to assistive technologies. See my post titled “Hiding content untagled” for more information.
Also, CSS :before and :after text is rendered to assistive technologies. So be aware what you put in there.
The clearer you separate the three, the more maintainable your code will be. Put CSS in their own files, don’t embed it in the HTML. Put JS modules in their files and don’t embed JS code in your HTML, either. This will make everything more readable, and remind you that the concepts should really be separate that just happen to work together rather than mingling uncontrollably.
Have you ever stood in the sunlight or another bright light source with your smartphone or tablet in hand and wondered why you couldn’t read something? Well, you were suffering from a lack of contrast between foreground and background on the page you were visiting. Low contrast ratios lead to bad readability in bright light situations. For the aging population, as well as low-vision users, low contrasts pose an even greater obstacle in readability. The Web Content Accessibility Guidelines define as a success criteria to have a contrast ratio of 4.5:1 on main content text to its background. You can use tools like the Colour Contrast Analyser to point at your content and see whether your visuals meet this requirement. Even if you’re not auditing for WCAG compliance, adhering to this rule of thumb is still a good idea for your own eyes as well as everyone else’s.
When you develop for the mobile web, and today it is most likely you are, please keep the Pinch To Zoom gesture alive! Do not disable this gesture vital to many more of your readers than you might think! Pinching to zoom something small on a web page is very common and does not apply only to aging readers as well as those with low vision. If your layout does not cope with the pinch gesture for some reason, you need to revisit your responsive design and fix it. Do not disable the pinch gesture on mobile browsers!
If you really need to implement advanced widgets that are not indiginous to HTML, take good care that you implement all aspects of them. I have some information on how to make clickable widgets that should be buttons or links, tabs and tabpanels, some auto-complete widgets and modal dialogs accessible. The friends at SSB Bart Group have a quite current post on ARIA tree views up, and Terrill Thompson conducted an extensive test of ARIA menus.
As you may have guessed by now, adhering to semantic structures that HTML already offers today will get you a long long way towards accessible web content. In fact, most web content that doesn’t need special widgets will most probably be over 90% accessible by just using proper semantics and honoring a few extras that are in styling.
Only if you need to use widgets that are not provided by HTML, will you really have to dig deeper and dive into standards like WAI-ARIA. But even its first rule is: Don’t use it if you don’t have to! Just sugar-coating everything with WAI-ARIA attributes you find in Google somewhere will do more harm than good. I promise!
Use semantics and save yourselves a lot of extra work, because all the standard elements come with accessibility for free.
Teach others! If you’ve mastered the skills of a good HTML and CSS citizen, teach others! Get involved, contribute your knowledge and share your wisdom! You’ll help at least two more than the obvious ones with every contribution you make!
I hope this article helps a little to clarify how easy it is to gain way over 80%, if not over 90% of accessible web content just by following standards and semantics! Please feel free to share your thoughts in the comments below, and if there is something I missed that you think should belong in this collection, feel free to also let me know, and I’ll add it!
This topic is also available as a video presentation held at the 2016 Global Accessibility Awareness Day’s Inclusive Design 24 event.