Jump to main content
Menu

Web Accessibility and ARIA

The Developer's Role in Accessibility

  • How a website or web application is coded is the single biggest factor in whether it is accessible.
  • Visual design has its part to play in accessibility, but that does little or nothing to help users with visual impairments (depending on the severity/type of the visual impairment).
  • Visual design decisions can make interaction easier for users with mobility impairments and cognitive impairments, but for the mobility impairments it is still reliant on the coding to be done properly, in order to support keyboard access and touch access.
    • For example, clickable targets need to be large enough and far enough apart to support accurate tapping, to support scenarios where the user has a motor tremor. And the targets need to be reachable using the tab key.
    • Keyboard focus also needs to be noticeable - the browser default is so slight that it is easily overlooked. 2px or 3px dotted #000 makes the focus large enough to stand out (the color would need to change depending on the background color).
  • Developers almost always have more work to do than their available time, but it is best to take an extra 15-20 minutes to make something accessible as it is being built, compared to spending hours later on trying to make an inaccessible setup work for assistive technology. No one wants to go back and rewrite their code, so just make it accessible the first time through!

Installing and Using Assistive Technology

  • Generally, the only software that you need to install are screen readers. These are programs that read aloud the website / web application content.
  • There are many screen readers out there, but the three that are generally used for testing/development are:
    • NVDA - This free screen reader is available for Windows. There is an NVDA user guide that is worth reading through and having handy as a reference as you use the screen reader.
    • JAWS - This is another Windows screen reader that has been widely used for many years. While not free, you can operate the screen reader without a license. Whenever you want to run it, you launch the software, reboot your computer, and then can use JAWS for 40 minutes. As with NVDA, there is JAWS documentation you can access.
    • VoiceOver - This is a Mac OS and iOS screen reader that is already installed on your Mac, iPad, iPhone, etc. Apple has published a VoiceOver user guide.
  • If you are on Windows, install NVDA and JAWS.
  • If you are on a Mac or using an iPhone, activate VoiceOver.
  • Then listen to web pages using the screen reader(s) - it is an enlightening experience.
  • For testing keyboard access all you need is a keyboard:
    • Use the tab key to move through the page (shift + tab moves backward in the tab sequence).
    • By default, the only elements that can receive keyboard focus are form elements and anchors. Through manipulating tabindexes and using JavaScript it is possible to put focus on other elements, such as divs, but the best practice is to just use the elements that were naturally meant for keyboard access.

WCAG and Section 508

  • In the United States it is increasingly common for businesses to be sued for their websites being inaccessible. Airlines are a common target, but e-commerce sites are targeted more and more frequently.
  • Generally the lawsuit is brought by an organization representing individuals with disabilities, and the cases are settled out of court. The company with the inaccessible website pays money and promises to make their website more accessible.
  • Some lawyers have also taken to sending threatening letters to a wide range of businesses, in the hopes of scaring them into paying some money to avoid a lawsuit. These are "fishing expeditions", with the hope of a quick payoff.
  • What is the basis for these lawsuits? Often it is non-compliance with the Americans with Disabilities Act (ADA), although not always.
  • The ADA has stipulated for decades that federal government websites, as well as websites of contractors working with the federal government, had to be accessible. Over time this expanded to state and local government, and from there to colleges and universities. Now it has reached the private sector.
  • The portion of the ADA that relates to information technology (and thus websites / web applications) is Section 508. It is an understatement to say that the United States government was slow to issue guidance for complying with Section 508 on websites.
  • While the government was trying to put together guidelines, the World Wide Web Consortium (W3C) had their Web Content Accessibility Group (WCAG) drafting their own guidelines. WCAG published their guidelines first, and the Section 508 guidelines were largely a copy of the WCAG guidelines.
  • In the years since those initial drafts, WCAG has evolved to version 2.2 and the Section 508 guidelines have been refreshed / updated. They still largely align, but WCAG is more expansive and is more up-to-date.
  • WCAG 2.2 is a large hierarchy, with four high-level principles (Perceivable, Operable, Understandable, Robust) that have sub-categories. At the lowest level of the hierarchy are checkpoints, which are the things that must be done to be accessible. Each checkpoint has a level assigned to it, which is either A, AA, or AAA. AAA are the hardest to achieve.
  • A website or web application targets a particular level of compliance with WCAG 2.2:
    • Level A Compliance: All checkpoints at Level A are met.
    • Level AA Compliance: All checkpoints at Level A and Level AA are met.
    • Level AAA Compliance: All checkpoints at Level A, Level AA, and Level AAA are met.
  • Most of the time, level AA compliance is the goal. Websites will sometimes have accessibility statements that, among other things, state the WCAG 2.2 compliance level.
  • There is an excellent WCAG 2.2 quick reference that you should explore. In particular, examine the techniques and failures for each checkpoint. Those are very informative and helpful, especially in cases where the phrasing of the checkpoint can be a challenge to understand. Once you have read the techniques and failures, the intention of the checkpoint will be clear.
  • Section 508 has its own checklist in Excel, which is still referencing WCAG 2.0. However, the phrasing for those checklist items is clearer.
  • In a court of law (assuming it gets that far and is not settled out of court), it would come down to testimony from accessibility experts on both sides regarding how the website or application has, or has not, been made accessible enough.

ARIA

  • ARIA (Accessible Rich Internet Applications) is a W3C specification for improving website accessibility.
  • ARIA introduces a large number of new attributes to HTML5. We will cover a limited set of the new attributes in this article. There is more to ARIA than what is covered here.
  • Windows and Mac OS have, for decades now, had ways for screen readers and other assistive technology to communicate directly with software written for that operating system. For example, a Word document could pass a significant amount of data to a screen reader and the data could be rich and very informative, organized into an information hierarchy.
  • In contrast, for most of the years that we have had the Web, screen readers have had to rely solely on what was in the HTML and just read that. It was a very limited approach. Browsers could not access the same information bridge (API or Application Programming Interface) as other native programs, and even if they did access it, there was no way to properly classify / organize the website data.
  • With ARIA, we now have an approach that uses the same communication channels as Word and other native programs to pass data directly to the screen reader, and organize it into the same rich data hierarchy.
  • The origin of ARIA is linked to the rise in the late 1990s and the early part of this century of websites / web applications that were doing all sorts of crazy things in their user interfaces, such as making divs behave as buttons (using lots of JavaScript). Those approaches were not accessible, and so ARIA allows for that div to be assigned the role of a button, and various other aspects/behaviors can also be detailed in the ARIA attributes so assistive technology can properly understand, and communicate, what is happening and can know the current state of the button (for example, is it active or not).
  • It is always the best practice to use the appropriate markup for a given control (button, anchor, etc.), because then in most cases no ARIA is needed; assistive technology properly handles that markup. That is much better than trying to make a div behave like a button and be described as a button.

Landmark Roles

  • Landmark roles are used to identify major areas / regions, so that this can be communicated to assistive technology.
  • The role attribute is used and there are eight values:
    • banner - the masthead of the page; only have one per page
    • complementary - content that complements the main content but is also meaningful when used in isolation
    • contentinfo - copyright and privacy statements; only have one per page
    • form - contains form elements
    • main - contains the main page content; only have one per page
    • navigation - a navigation bar
    • search - a form used for a search engine's input
    • application - this would be for a software application that handles all of its commands on its own, rather than using the browser
  • In practice, only role="contentinfo" and role="search" are needed for most websites and web applications, as choosing the most appropriate markup handles the rest.
    • role="contentinfo" would be added to whatever container element is holding your copyright text (for example).
    • role="search" would be added to the <form></form> element for your search engine.
  • <header> has an implicit "banner" role, so that does not need to be specified.
  • <aside> has an implicit "complementary" role, so that does not need to be specified.
  • <form> has an implicit "form" role, so that does not need to be specified.
  • <main> has an implicit "main" role, so that does not need to be specified.
  • <nav> has an implicit "navigation" role, so that does not need to be specified.
  • If you were building your entire site with div elements then specifying the banner, complementary, main, navigation, etc. roles would be necessary, because none of those roles are implicit for <div>.

aria-label

  • The aria-label attribute is ideally for situations where a visible label is not available for a form element: 
    <input type="text" name="address" placeholder="Enter your address" 
aria-label="Enter your address" />
  • In the above example there was no visible label, and the placeholder attribute is not going to be reliably passed (or passed at all) to assistive technology, so aria-label was necessary.
  • Sometimes the value in use is also not sufficiently descriptive. For example, using 'X' for a button label is not clear as to the meaning/usage: 
    <button aria-label="Close">X</button>
  • This can also be applied to anchors, providing an opportunity to provide descriptive text when the text provided is poor: 
    <a href="link.html" aria-label="Read the article about HTML5">Read more...</a>
  • Of course, the ideal approach to the prior example was a descriptive, helpful link phrasing, but that wasn't happening on its own and the client wanted those to be 'Read more...' (to users looking at the page).
  • You cannot use aria-label everywhere. It is limited to form elements, anchors, and structural markup (header, nav, footer, etc.) You cannot put it on a div, for example. It does provide a nice introduction to a navigation bar if applied to the nav element.
  • Only one label will be read for a given element and aria-label will override all the other options, so it takes precedence and is read instead.

aria-labelledby

  • This attribute is used to associate elements with visible labels.
  • If this seems like it is already covered by the <label> tag, that is indeed the case for form elements.
  • However, there are other scenarios than form elements. For example, if you use <section>, the best practice is to have heading(s) within that <section>, and to use this attribute to identify the most relevant heading for that section, using the id assigned to the heading. For example: 
    <section aria-labelledby="subhdr">
  <h2 id="subhdr">Main heading for this section</h2>
  <p>Other text in this section</p> 
  <p>Other text in this section</p> 
</section>
  • In the previous example, this communicates to assistive technology what label to use when giving information about the section.

aria-describedby

  • This attribute is used to provide additional descriptive text, beyond what a label communicated.
  • The description would be read when the element gains focus.
  • The id is again used, but this time it is the id assigned to the container holding the description.
  • For example, this can be used to associate a form input with its error message. Or it could be used to communicate instructions for a form element: 
    <label>Phone: <input type="tel" 
name="phone" aria-describedby="phoneInstructions" /></label>
<div id="phoneInstructions">(format: XXX-XXX-XXXX)</div>

aria-live

  • Assistive technology, such as screen readers, will take a snapshot of the web page's code when the page loads and will store that in memory.
  • This allows the assistive technology to work much faster, because it has a local copy that it can work with, and does not need to keep going back to the browser as it reads text / outputs text.
  • This is problematic if the web page or web application is dynamically re-populating areas of the page, such as refreshing news headlines, updating stock prices, or displaying matching products in real-time as you apply filters or type in a text box.
  • The best approach in those cases is to specify aria-live="polite" for the container element where the content / markup is changing. That tells the assistive technology to monitor that specific area in the code for changes, and report the changes when there is a reasonable opportunity to do so.
  • The alternative is aria-live="assertive", which would only be appropriate if the update was urgent, such as being logged out due to inactivity in 30 seconds, or a tornado being spotted two miles away from your location. Assertive breaks off whatever the assistive technology was doing and reports the change as soon as it can.

aria-controls and aria-expanded

  • These attributes are used to indicate when one element, such as an anchor or button, controls the appearance or status of another element, as well as the state of that controlled element.
  • The aria-expanded is set to either "true" (it is expanded/shown) or "false" (it is collapsed/hidden).
  • The id attribute value is used again.
  • For example, lets assume you have an expanding/collapsing set of linked headings and associated content areas: 
    <h2><a href="#" aria-controls="q1text" aria-expanded="false">Question 1:
 Question text...</a></h2>
<div id="q1text">The answer to the question</div>

<h2><a href="#" aria-controls="q2text" aria-expanded="false">Question 2:
 Question text...</a></h2>
<div id="q2text">The answer to the question</div>

<h2><a href="#" aria-controls="q3text" aria-expanded="false">Question 3:
 Question text...</a></h2>
<div id="q3text">The answer to the question</div>
  • For the example, assume that the answers are hidden (likely via display: none) when the page loads.
  • When the anchors are clicked, JavaScript is used to display the associated answer (likely display: block) and JavaScript toggles the aria-expanded to be "true" and also disables the href action so the page does not reload. When the anchor is clicked again, JavaScript adjusts display of the answer and sets aria-expanded="false" when the answer is hidden.
  • As the user is toggling the answers open and closed, the assistive technology is reporting what is happening with the answers being expanded or collapsed, and has associated the answer with its prompt.
  • It's worthwhile to note that display: none hides content from screen readers, so be mindful of that. You don't want to inadvertently hide something critical from a screen reader user.
  • You might also wonder why aria-live="polite" was not used here. That is only used if the content was changing or loading when you clicked the question, and the content is already there in the page. All we are doing is showing or hiding it, so there was no need for that attribute.

PDF Accessibility

  • PDF documents also fall under WCAG and Section 508, and are often overlooked.
  • If you have Acrobat Pro, there is a PDF accessibility checking process that you can run.
  • Most of the time, the items that are missing are a title for the PDF (which can be set in its properties), tagging for content such as tables and lists, and alt text for images/objects embedded in the PDF.
    • Acrobat Pro can auto-tag the document, which is a big time-saver.
    • Otherwise you're going back to the source document, making edits, and re-generating the PDF.

Testing Tools

  • Testing tools are of limited value - they can find some accessibility issues, but not all of them.
  • They do fine at identifying straightforward issues that are based entirely on the markup, such as "Does this image have an alt attribute?"
  • However, they cannot identify whether an image that does have an alt attribute has useful, informative text there. That is beyond the software's capabilities.
  • These programs also cannot "see" background images, so if you have white text against a dark background image, you will probably get flagged as having a contrast issue, because from the software's perspective you have white text against the white browser window background.
  • One of the more commonly used tools is WAVE, although it has its shortcomings.
  • The best way to test accessibility is to have users with impairments use the website or web application, while you take notes and gather data. The next best thing is to do your own testing and walk through the code yourself.