4.1.2 Name, Role, Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. (Level A) WCAG 2.0
When I do training on advanced accessibility, attendees are sometimes taken aback when I tell them that HTML is a “polite request”, but it is true. As web developers we like to think that our hard work creating HTML, CSS, and JavaScript is what makes our sites so great, but the reality is that all our hard work is really just a request that says “Please, Mr. Browser, can you make this website do all the cool stuff I’ve designed here?” At the time the user’s browser actually receives your web page and all of its assets, your control of the situation entirely ceases and control for how your site really looks and operates is entirely in the hands of the browser.
For those of you who’ve been online since the 90s, at no time was this more clearly demonstrated than in the Browser Wars of that time, in which it was very possible for a website to look and work quite differently depending on what browser and operating system the visitor used. In response, many web technologists joined forces to push for standards compliance. Among the results of this push was the DOM specification. DOM, or Document Object Model, is “a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents. The document can be further processed and the results of that processing can be incorporated back into the presented page.” The DOM specifications themselves don’t actually dictate exactly what a browser must do.
The Document Object Model (DOM) is an application programming interface (API) for valid HTML and well-formed XML documents. It defines the logical structure of documents and the way a document is accessed and manipulated. (Source: W3C)
The DOM API defines an extensive series of interfaces which identify the properties and methods that a Document Object should have. In Object Oriented Programming, an Interface is a description of what properties and methods an Object of that type must have. For instance, an Interface for a “car” object would have properties of “doors”, “wheels” and an “engine” and methods like “drive” and “turn”, but the interface would not dictate exactly how the final car object actually does those things. That would be up to the automaker to decide.
A great thing about Object Oriented Programming, in general, is the concept of Inheritance which allows you to create new classes of objects that build upon the basic object to create new, different objects. Here’s the basic Interface for an HTML element.
interface HTMLElement : Element {
attribute DOMString id;
attribute DOMString title;
attribute DOMString lang;
attribute DOMString dir;
attribute DOMString className;
};
That interface tells us that the basic HTML element can have a number of properties: id, title, lang, dir, and className. You may also notice that these are all attributes in HTML (except for className which is simply the ‘class’ attribute in HTML). You may also notice that these attributes are available in all HTML elements.
What you don’t see in that Interface definition are any methods. In other words, a basic HTML element, like a SPAN element, has no methods available to it. It can’t do anything. Let’s look at something a little more interesting: an INPUT element.
interface HTMLInputElement : HTMLElement {
attribute DOMString defaultValue;
attribute boolean defaultChecked;
readonly attribute HTMLFormElement form;
attribute DOMString accept;
attribute DOMString accessKey;
attribute DOMString align;
attribute DOMString alt;
attribute boolean checked;
attribute boolean disabled;
attribute long maxLength;
attribute DOMString name;
attribute boolean readOnly;
// Modified in DOM Level 2:
attribute unsigned long size;
attribute DOMString src;
attribute long tabIndex;
// Modified in DOM Level 2:
attribute DOMString type;
attribute DOMString useMap;
attribute DOMString value;
void blur();
void focus();
void select();
void click();
};
There’s a bit more to deal with in that interface declaration of an INPUT element. The first thing to note is the first line: interface HTMLInputElement : HTMLElement {.... This means that the HTMLInputElement interface extends the HTMLElement interface, inheriting its properties: id, title, lang, dir, and className. It then builds upon that by adding 18 more properties. It also defines 4 new methods: blur(), focus(), select(), and click(). These methods declare what behavior should happen when these methods are called.
Note: I’m using DOM Level 2 information mostly because it is easier for the layperson to absorb. Currently DOM Level 4 is in the works and HTML5 contains a large number of changes/ additions which refer to DOM4.
Because these are Interfaces and not the actual classes, the final implementation of them is up to the browser vendors, who decide to include whatever they think is best for their customers. This isn’t to say, however, that the DOM specifications leave implementers high and dry and it is the Wild West out there. Explicit guidance is provided in the specifications as to what each property and method intends. For instance, DOM Level 4 defines the getAttribute() method as follows:
The getAttribute(name) method must run these steps:
- If the context object is in the HTML namespace and its node document is an HTML document, let name be converted to ASCII lowercase.
- Return the value of the first attribute in the context object’s attribute list whose name is name, or null otherwise.
Ultimately, there’s no law, regulation, or policy which dictates that browser manufacturers adhere to specific DOM specifications, nor is there anything which calls for them to adhere in any specific way. Browser vendors, like any company, make up their own minds regarding what features are or are not a priority for their particular product based upon how they feel their customers will be served. This is easily seen these days by the wide variations in support for the new HTML5 input types.
It so happens that, for the most part, modern browsers adhere to the DOM specifications rather closely (some better than others). The browser’s layout engine (also often called the Rendering Engine) takes the document and uses it as instructions to create the objects. Those final browser objects may have additional methods and properties as defined by the vendor. They may look differently and may have different sizes or positions. For the most part, they’re typically consistent, thanks to standards.
What does this all have to do with Accessibility?
To review, the web developer creates a series of HTML, CSS, JavaScript and other files and places them on the website’s server. The user visits the site with their browser which submits a request over HTTP (or HTTPS) for a URI. The server responds by sending over the necessary files to display the page. At that point, the browser’s rendering engine turns those files into a series of objects which are then displayed on the screen. Each of those objects have specific methods and properties available to them. From these objects, assistive technologies are able to convey important information, typically through the use of an accessibility API.
The W3C’s WAI-ARIA specification provides an excellent description of accessibility APIs:
In the case of static Web pages, the Document Object Model (DOM) is used to represent the structure and state of the elements in the document being rendered by a user agent. The elements of the document are organized into a hierarchy of nodes known as the DOM tree. For traditional static Web pages, assistive technologies, such as screen readers, interact with user agents using the DOM. For UI elements that are known to be interactive, such as HTML form elements and desktop applications, assistive technologies may use platform accessibility APIs. … The screen reader or other assistive technology uses the semantic information exposed via the accessibility API to provide an alternative rendering of an application that is meaningful to a user.
In short, in all cases – regardless of whether the user has a disability or not or uses an assistive technology or not, the thing they experience are the objects created by the browser. Users of assistive technologies rely on the information they receive about these objects in order to understand what things are, where they are, and what they’re doing. In other words, they need to know objects’ name, state, role, and value.
The Name of an object is, well, its name. For instance, in the case of a BUTTON element, the ‘name’ of that element would be the text within the button. For an INPUT element, the name would be its label. In other words, the name says: “What do we call this thing?”
The State of an object describes what this thing is currently doing, if it can do things. Implicitly, it also often describes what else this thing can do. For a checkbox, for example, its current state could be “checked”. This implies therefore that it could also be “unchecked” (unless it is readonly, of course).
The Role of an object declares what it is. In other words, using our previous example, the object would have a role of “checkbox”. Or, more specifically, it would have whatever role that the operating system or accessibility API says is the role for checkboxes. MSAA and UIAutomation would use ‘ROLE_SYSTEM_CHECKBUTTON’ to identify its role.
The Value of an object is, er, the value. Whether this exists or not and what its value is depends significantly on the type of object. Perhaps the easiest way to understand this would be to again use our checkbox analogy. Provided the following code: <input type="checkbox" name="agree" id="agree" value="Yes" /><label for="agree">Do you agree Karl is awesome?</label> the value for this checkbox would be ‘Yes’ (when in a checked state).
Why Name, State, Role, and Value are important
What? You mean 1600 words later it isn’t obvious? OK, here goes. When people talk about many of the requirements for web accessibility, they’re really talking about Name, State, Role, and Value.
- Alt text for images? The alt becomes the accessible name for the image object.
- Providing explicit form labels? The label becomes the accessible name for the associated form field object
- Keyboard accessibility? A lot of that has to do with Role and State of the actionable objects.
- Advice against using DIV or SPAN as a button (or any other form control for that matter)? That’s pretty much all four – Name, State, Role, and Value (or lack thereof in the case of DIV and SPAN).
Many of the accessibility violations relating to the use of client-side scripting are mostly due to not properly managing Name, State, Role, and Value information of custom controls. You can (and should) avoid these problems by first opting to use HTML’s standard elements and attributes in the manner in which they were intended. For instance, a BUTTON Element already has a number of methods and properties available to it that you’re likely to forget about (or skip altogether) if you were to make one out of a <DIV> and bind some events to it. Can you use WAI-ARIA? Sure, but why? You’d still have to handle reacting to both keypress and click events, ensuring the item is in the tab order, and indicating the role. If you want to disable the button, you’d have to script that and ultimately you’re doing a whole bunch of work you don’t need to because using the right element for the job means accessibility is free. WAI-ARIA is best used to bridge gaps where the desired type of object or interactivity isn’t available in already existing core functionality or that core functionality isn’t yet broadly supported by browsers.
There’s a lot to learn and a lot of information to keep abreast of when it comes to accessibility. Fortunately, most of these things fall under the Four Principles of accessibility and in understanding the importance of Name, State, Role, and Value. Once you’ve fully grasped those things, you’re far on your way to creating more universally usable web experiences.