Web Directions Year round learning for product, design and engineering professionals

As the excitement builds for our Respond 17 conference (Early Bird closes 24 March), we have another Wrap magazine summary of a presentation from Respond 16.

And not just any presentation. Russ Weakley is one of those Australians who has built an enviable global reputation as someone who not only has a comprehensive and detailed understanding of CSS and its role in delivering superior web experiences, he can also convey that understanding to others – which he’s done in books, articles and video courses accessed by thousands of people.

A particular focus of Russ’s work is accessibility, a topic that strikes fear into the hearts of many but which Russ insists can be achieved without tears. This Wrap summary gives you a good idea of the clarity and directness with which Russ approaches the topic.

Building accessible web components without tears

Russ Weakley, Web Designer, Max Design

Key points

Many web applications these days are built on top of pre-existing frameworks or code bases and there is little thought to how well these components will work for different assistive devices.

A range of common application components can be made accessible – quickly and easily – for all users, including forms, modal windows, drop-down menus, in-page tabs and other commonly used web components.

A simple way for a web developer to understand accessibility is to try to navigate a site using only a keyboard. If they cannot perform all tasks without issues, tell which element is in focus at any time or tab around the page in a logical order, then that site has accessibility issues.

Fluency or even dependence on libraries and frameworks can lead to developers forgetting core web principles: basic HTML, CSS, accessibility and progressive enhancement.

If we want to make our sites available to the widest possible audience, we have to include people with various types of disability, many of whom use assistive devices for input (keyboards, trackpads, head wands, puffers, switches, touch screens, voice activated software) and output (text browsers, screen readers, magnifiers, Braille devices).

“The best time to focus on accessibility is right at the beginning of the development process, when creating the individual components in your pattern library.”

Takeways

Screen readers often dominate discussion of assistive devices but in fact keyboard only users constitute a bigger group of users (because it includes screen readers), and all types of AT should be considered.

WAI-ARIA defines a way to make websites more accessible, especially JavaScript components. We can use specific HTML attributes to define roles, state and properties for HTML elements, and thereby make those elements more meaningful for assistive technology.

Dynamic content presents some specific accessibility issues. For example, content that tells a user something in response to a user action may not be conveyed by a screen reader because it has already buffered the page and can’t re-read it, or because it can only focus on one part of the screen and thus doesn’t pick up the added content.

The aria-live attribute can be applied to any HTML element to tell screen readers about changed content, with different levels of urgency. Aria-relevant, with its values of additions, removals and text, gives an idea of the type of content that has changed, while role=alert can also help to define how and when the user is alerted.

If a screen reader is in “forms” mode (as opposed to “read” mode), it may not announce content that is near but not directly atached to the form controls. Because of this, many users will switch between read and forms mode to make sure they get all the info they need to complete the form.

Form validation can present problems for screen readers as error messages may appear after a form control has lost focus. The screen reader may have to go back over the form to find the error message. There are various ways to let assistive technology tell users about form errors. Familiarise yourself with them and use them.

Modals can also present problems for AT. A user may find that they can tab outside the modal window while the modal is active, but a screen reader can’t always tell a blind user that a modal has been triggered, let alone whether the user is in or out of the modal window. We can programmatically tell the screen reader how to treat the modal and tell the user what’s going on.

In-page tabs and panels also need some work to make sure a user of assistive technology understands what’s going on, what they can do, what they should do and what will happen as a result of their actions.

ARIA gives us the programmatic language to do this. Note that the steps you take to achieve this will tend to be useful to all users.

“Web accessibility begins with semantic markup.”

Caveats

As aria-live=”assertive” is not well supported by browsers, it may be preferable to stick with aria-live=”polite”.

Whatever you do, make sure you test: using keyboard only yourself will tell you a lot, use accessibility checking tools, test with screen readers, and conduct formal accessibility audits when needed.

It’s important to note that it may not be necessary to do all that is described here. Aim for quick wins that deliver the most accessibility to users of assistive technology. Solve the problems that prevent users from completing actions first and then aim for making things progressively easier.

Resources

@russmaxdesign
website
slides

Tweets