Accessibility as you go: Part 3

Picking up where we left off in Part 2, in which we went over some of the tools and design considerations for accessibility, in Part 3 we’ll review some tips for minimizing accessibility issues by addressing them early in the development process.

Plan your DOM order

DOM is Document Object Model, which is the fancy name for the tree-like structure of the HTML (or XML or SVG) markup. For accessibility, it’s important (or at least helpful) for the DOM order to match the visual order of the content. This can sometimes get messed up, especially when positioning various blocks in header areas, or when creating the layout. If you have control over where things are positioned in the markup, try to match it to the flow of the design, top down and left to right (instead of forcing out-of-order layout with absolute positioning, for instance).

If you are unable to adjust the DOM order to match the designs, you might consider adjusting the tabIndex to make sure users tabbing through the content traverse the site in the proper order. (WebAIM disagrees, saying not to use tabIndex at all because if you find yourself needing to implement it, your natural navigation order probably needs an overhaul.)

Test keyboard navigation often

Spend some time just tabbing through your site and ask yourself some questions:

• Can you do everything with the keyboard only that you could do with a mouse?
• Can you expand all menus?
• Can you skip to the menu AND skip to the content immediately?
• When you tab to different items, do they appear with a well-defined “focus” state?

If there are links or toggles that are not anchor tags, you may need to give them a tabIndex. This will make it so you use them purely with a keyboard (using the tab key). If you are writing javascript click() functions, you may need to add focus() to make the function work with a keyboard.

JavaScript – less is more

When it comes to JavaScript and accessibility (and most website concerns), less is more. JavaScript can certainly be used to solve some accessibility issues (adding a tabIndex, changing the DOM order when going from a large width to a small, showing and hiding skip links, etc). It’s still best to use it sparingly since it may introduce NEW accessibility problems (functions that only work for mouse, not keyboard or ordering issues between breakpoints).

Before adding more JavaScript, ask yourself:

• Is there is a way I can do this with CSS rather than JavaScript?
• Can I just use JavaScript to toggle a class which will then, in turn, enable it to be done with CSS?
• If it’s DOM order problem, can I fix it in a template first?

More JavaScript = more problems.

Alt text strategy

A11y tools will complain if any of your images don’t have alt attributes. If you are using a content management system, make sure all of your image fields are able to accept alt text.

If the images are content, not decoration, make the alt text a required field. This is an important distinction: decorative images should have “silent” alt attributes — include the attribute, but leave it blank. This looks something like: <img alt="" src="example.jpg" /> . Decorative images may not be limited to graphics; stock photography also may be decorative — describing a generic “smiling woman” may not be worth the characters.

Content writers should also make a distinction between alt text, title text and captions:

• Alt text never appears on the screen unless an image is broken. It is used both by screen readers for users with low vision and by search engines. Generally alt text should not be descriptive, but rather convey the content and purpose of the image. In short, it’s more of an art than a science, but keep it informative and concise.
• Title text is also an attribute on the image tag; it’s the text that will appear when you hover over the image. It should never be used for vital information since screen readers generally skip it. Do not duplicate the alt text or caption — it’s not needed.
• Captions print beneath an image and are readable to all users. If you DO have a caption, then you should keep alt text short, and nix title altogether.

Fill those tags

Empty tags make accessibility checkers sad.  If you need to replace a div or link with an image, be sure to include content within the tags. We use a simple Sass mixin to hide text:

// Hide text
@mixin hide-text {
 overflow: hidden;
 text-indent: 99999em;
 white-space: nowrap;
}

Trusted libraries only

When choosing a library to plug into your site — which is inevitable with any complex site — be sure to review that their code introduces accessible markup before heading down that road. Sometimes you can find chatter about it in their issue queues, and sometimes you can just do some testing on their demos.

Website accessibility is a deep and often complicated topic, but achieving Level A or AA standards can be straightforward by addressing it early in your design and development processes.