WCAG accessibility conformance and WAI-ARIA for more accessible web applications
Even since writing the first edition of this book in 2011/2012, the W3C has made great strides in making it easier for authors to make the necessary adjustments to code to make web pages more accessible.
Web Content Accessibility Guidelines (WCAG)
The Web Content Accessibility Guidelines (WCAG) exists to provide:
a single shared standard for web content accessibility that meets the needs of individuals, organizations, and governments internationally
When it comes to more pedestrian web pages (as opposed to single-page web applications and the like) it makes sense to concentrate on the WCAG documentation. They offer a number of (mostly common sense) guidelines for how to ensure your web content is accessible. Each recommendation is rated by a conformance level: A, AA, or AAA. For more on these conformance levels, visit http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-levels-head.
You'll probably find that you are already adhering to many of the guidelines, like providing alternative text for images, for example. However, you can get a brief rundown of the guidelines at http://www.w3.org/WAI/WCAG20/glance/Overview.html and then build your own custom quick reference list of checks here: http://www.w3.org/WAI/WCAG20/quickref/.
I'd encourage everyone to spend an hour or two to look down the list. Many of the guidelines are simple to implement and offer real benefits to users.
WAI-ARIA
The aim of Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA) is principally to solve the problem of making dynamic content on a web page accessible. It provides a means of describing roles, states, and properties for custom widgets (dynamic sections in web applications) so that they are recognizable and usable by assistive technology users. For example, if an on-screen widget displays a constantly updating stock price, how would a blind user accessing the page know that? WAI-ARIA attempts to solve this problem.
How to implement ARIA fully in something like a web application is outside the scope of this book. However, if that's the kind of project you are building, head over to http://www.w3.org/WAI/intro/aria for more information. Instead, let's just go over some of the most important headline points to consider about ARIA.
The first important point to note is that it used to be advisable to add landmark roles to headers and footers like this: <header role="banner"> A header with ARIA landmark banner role </header>. However, role="banner" is now considered surplus to requirements. Look at the specifications for any of the elements we have looked at and you will see a dedicated Allowed ARIA role attributes section. Here is the relevant quote from the <section> element as an example:
Allowed ARIA role attribute values: region role (default - do not set), alert, alertdialog, application, contentinfo, dialog, document, log, main, marquee, presentation, search or status.
The key part there is "role (default - do not set)." This means explicitly adding an ARIA role to the element is pointless as it is implied by the element itself. A note in the specification now makes this clear:
In the majority of cases setting an ARIA role and/or aria-* attribute that matches the default implicit ARIA semantics is unnecessary and not recommended as these properties are already set by the browser.
Therefore, the easiest thing you can do to aid assistive technologies is use the correct elements where possible. A header element is going to be far more useful than div class="Header". Similarly, if you have a button on your page, use the <button> element (rather than a span or another element styled to look like a button).
Taking ARIA further
If you want to explore a solid set of accessible design patterns, the W3C has a published set you can peruse here: https://www.w3.org/TR/wai-aria-practices-1.1/examples/#examples_by_props_label.
Test your designs for free with NonVisual Desktop Access (NVDA)
If you develop on the Windows platform and you'd like to test your ARIA enhanced designs on a screen reader, you can do so for free with NVDA. You can get it at the following URL: http://www.nvda-project.org/.
Google now also ships the free Accessibility Developer Tools for the Chrome browser (available cross-platform), which is well worth checking out.
There's also a growing number of tools that help quickly test your own designs against things like color blindness. For example, https://michelf.ca/projects/sim-daltonism/ is a macOS app that lets you switch color blindness types and see a preview in a floating palette.
Hopefully, this brief introduction to WAI-ARIA and WCAG has given you a little background information on supporting assistive technologies. Perhaps adding assistive technology support to your next HTML project will be easier than you think. As a final resource for all things accessibility, there are handy links and advice galore on The A11Y Project homepage at http://a11yproject.com/.