Coding Accessibility: An interview with Steve Faulkner

An edited version of this interview appears in Chapter 6 of A Web for Everyone.

Steve Faulkner has been an accessibility engineer since 2001, first with Vision Australia and currently with The Paciello Group. He has a hand in developing HTML5 and WAI-ARIA specifications as a member of W3C working groups, and is editor of W3C specifications on HTML5, Using ARIA in HTML, accessibility APIs, and text alternatives. In short, Steve has accessibility chops.

Because much of what’s needed is beneath the surface of a page, we asked Steve to explain what user experience designers should know about how code supports accessibility.

Elements of an accessible user interface

Web accessibility is largely about providing the information needed to make a user interface accessible to assistive technology, or AT. This is accomplished via an accessibility application programming interface, or API–a standardized way of specifying elements of an interface. A primary goal of an API is interoperability, where different devices and software can all use the same elements. For accessibility, Steve explains, “One piece of the puzzle is for information to be defined by an accessibility API. The second piece of the puzzle is for AT to make use of it.”

For the web, every HTML element has a role, states, and properties that are defined in the technology specification–“What it is, what it does, and where it’s at, at this point in time.” That information is expressed by the accessibility API in the browser, so that assistive technology can make use of it. “For example, with a heading, one of the properties might be its level, and whether it’s editable, visible, or linked.” The role, state, and properties information in the accessibility API allow assistive technology to, for example, create a list of headings or move keyboard focus to the main heading of a page.

Unfortunately, browsers and assistive technology don’t always make use of the accessibility API. “We’re always told to use <strong> and <emphasis> rather than <b> and <i> because they have semantic meaning, but the semantic meaning is not consumed by anyone” because browsers and assistive technology don’t make use of the information.

An accessibility API needs more than HTML

There are gaps in how native HTML elements support the accessibility API, because of how they are specified and how they are used. “Some decisions about what goes into HTML and what doesn’t don’t take into account accessibility requirements.”

For example, the role “main” is not represented in the HTML5 specification as an element, despite the expressed need for AT users to move cursor focus to the main content area. Other roles are defined, such as header, footer, and navigation: “I guess the thinking was, anything that’s not something else must be the main content.”

Also, HTML elements are not always used correctly. As an example, Steve explains that HTML buttons have been part of the specification for 15 years. However, developers build custom buttons using elements like images and links that are coded to behave like buttons. Typically, this is because of constraints imposed by visual design requirements. “They have to please whoever makes the design decisions. To achieve a certain visual effect across different browsers and platforms, they can’t always use standard controls.”

In these cases, HTML cannot provide the necessary information to make the interface accessible. “WAI-ARIA is the only way to supplement the necessary information for assistive technologies.”

WAI-ARIA fills the gaps

WAI-ARIA fills out the accessibility API, enhancing the descriptive information contained in native HTML controls and back-filling information for elements that are used for other than their intended purpose.

For example, ARIA provides explicit roles and properties to assist in wayfinding for users of assistive technology. Like “stepping stones,” ARIA landmark roles allow assistive technology users to step through the content of the page to find the content area of interest.

As with most accessibility features, information provided for accessibility could be of use to all users. “ARIA landmark roles would be of great use to users who navigate by the keyboard, but the roles are not exposed as navigable elements by browsers.” Assistive technology makes use of the roles, but as of this writing, no browser does. Another possible application would be to dim regions of the page that do not have focus in order to reduce distractions. Landmarks could also be used in the print view of a document, providing users with the option to hide elements like navigation that have little use on paper.

Accessible code in the real world

Steve is editor of four W3C specifications: HTML 5.1, Using ARIA in HTML, HTML5: Techniques for Providing Useful Text Alternatives, and HTML to Platform Accessibility APIs Implementation Guide. To inform his work, he started a data-mining project in which he downloaded the home pages of the top 50,000 websites and began analyzing how designers and developers were using elements, specifically HTML5 and ARIA code. “Those of us who develop standards define how things should be used and hope that developers follow the guidance so users get the benefit. But unless we actually look at the way they are being used, we can’t know whether they are actually being used in the right way.” His hope is that, by analyzing and identifying patterns of real-world code, he will be able to provide more practical guidance.

For example, in HTML5, there’s a new “placeholder” attribute that allows you to display a hint in a text field, such as “Enter your first name.” Some sites use “placeholder” as a field label, in place of the <label> element. In this case, Steve can recommend that browser’s use “placeholder” in “accessible name calculation” to convey information to assistive technology users about form fields.

Steve is also learning how much and how effectively HTML5 and ARIA are used in mainstream websites: for example, how ARIA landmarks, such as role=”main”, role=”banner”, and role=vcontentinfo”, are implemented. While he found that usage was low, he was “both surprised and pleased” to find that landmarks are being used correctly. “The specification says, for certain landmarks, you should have one per page, and overwhelmingly they are being used per specification, with one per page.”

HTML5, ARIA, or both?

In general, support for ARIA is more robust than accessibility support for new HTML5 features, due to its age and attention paid to getting ARIA support in mainstream tools. While ARIA has been providing landmark support since 2006, as of this writing, the HTML5 spec is still in the works. In addition to maturity, ARIA has benefited from successful collaborations between accessibility experts, such as IBM, and browser and AT vendors, such as Firefox and Freedom Scientific.

As a result, ARIA support is strong in most software. “I’m not saying that it’s good across the board, mainly due to some AT vendors just putting their heads in the sand, which has the effect of doing a disservice to their users.” And you can count on support for ARIA into the future. “As far as ARIA is concerned, it will remain relevant for many years to come. As new issues and technologies emerge, there will be new related updates to the ARIA specs to fill in any gaps.”

It’s best to think of ARIA as complementary, with HTML providing the core elements and ARIA filling the accessibility gaps as needed. “A good rule of thumb is, when there’s a native HTML structure, element, or attribute that’s well supported, use it. If that’s not enough, use the appropriate ARIA semantics.” But Steve also points out that there’s no harm in using both HTML5 roles and ARIA landmarks, such as <nav role=”navigation”>, where <nav> is an HTML5 element and the attribute role=”navigation” is an ARIA landmark role.

Advice for project teams

Steve encourages developers to go ahead and add ARIA landmark roles to current projects. “The good thing about landmarks is that you can add them to your current code, and they don’t have any design effects.” For interactive widgets that provide complex interactions, he recommends looking to existing libraries, such as JQuery or Dojo–code with WAI-ARIA already built in.

But he also sees the need for a change in mindset in how designers build websites and applications. “You tend to find back-end coders developing front-ends without understanding what makes a user interface usable, let alone accessible.” This is because project efforts often focus on the business transactions that occur on the back end, with little thought given to the user interface. “HTML development is often seen as monkey work that’s given to junior developers, or given to back-end developers who tack the front end on, and they don’t understand how to develop a user interface correctly, they don’t understand how to use HTML correctly, and then you see applications built without semantics.”

On the design end, Steve urges designers to understand that design elements are not just “pixels on a page,” but rather semantic containers for information described in code. “I don’t think designers need to know how to code. They do need to understand that there’s a give and take between what can be done given the requirement to actually code.”

Overall, he believes that project teams must include user interface expertise. “What’s needed is the realization within a team of the value of having people who understand usable UI design and can bring it to fruition using the code.”