Rationale

The current HTML 5 draft of this section seeks to ensure the preservation of host language semantics with the belief that authors should not use script and CSS to produce content that does not match the intent of the native host language semantics in HTML.

HTML5 provides the author the tools to use script and CSS on every HTML element allowing authors to create custom UI components that do not match the intent of the host language semantics. It is the considered judgement of the accessibility architects that to address accessibility, authors must be provided the ability to convey the necessary implied accessibility semantics in these scenarios as long as the application of these semantics does not introduce conflicts supporting platform accessibility services by the browser.

Since HTML 5 provides the ability to extend the functionality of HTML elements without programmatic restriction our approach must address the broader scope that web application authors will take which is to produce custom UI components.

They may also modify the visual appearance of any HTML element using CSS.

Using a combination of the above HTML features authors can modify the behaviour and appearance of most elements in a way that overrides the default semantics of an element. When authors do this it is often the case that the semantics and interaction behaviours conveyed to one class of users (assistive technology [AT] users) is different from the semantics and interaction behaviours conveyed to non-AT users. The authors intent for the interactive content in the document is not conveyed to AT users. This results in AT users not understanding the interactive content and/or not understanding how to interact successfully with the content. Adding ARIA roles, states and properties to elements whose semantics have been changed in this manner allows the semantics exposed to AT users to be made the same as those exposed to other users.

The current text in the HTML5 spec places severe limits as to what ARIA roles can be added to which elements in an effort to dissuade developers from using HTML5 elements and attributes incorrectly, unfortunately the point at which authors are alerted to potential conformance issues is only when ARIA is added to make thier inaccessible code usable by people with disabilities. This is a major failing of the current ARIA use in HTML5 conformance regime as it invalidates the accessibility repair mechanism, not the coding that is the root of the conformance issues and the cause of the reduction in the accessibility of the HTML5 content.

Conformance criteria must not used to lessen the probability that developers will use ARIA to make their content accessible, it should be used to ensure that when ARIA is used it is used correctly according to the WAI-ARIA specification and in such a manner that will improve the accessibility of the content it is applied to.

This proposal relaxes the restrictions of the current spec text to rebalance the conformance crtieria outcomes in favour of fulfilling ARIAs role as an accessibility repair method, while still disallowing aria markup that does not make sense. It does not allow overrides of widget roles by unrelated widget roles, nor does it allow for overriding of aspects of elements. Widgets can always be overridden by their children in the ARIA role taxonomy. This is because children are more specific versions of the same concept.

basis for changes to allowed roles, states & properties

basis for changes to command roles

The ARIA Role data model defines an “is-a” relationships between various roles. Items lower in the data model are more specific versions of higher items. So, for example, a menuitemcheckbox is a menuitem, and it is a checkbox. In HTML 5, checkboxes become menuitemcheckboxes when they are included in a menu. ARIA allows either a menu-item or a checkbox to be repurposed as the more specific menuitemcheckbox.

This concept is embodied in the 13th of the Guiding factors for decisions on ARIA Role use:

13.Any element’s implied role could be overridden by roles that inherited from it in the taxonomy tree. For example, meuitemcheckbox inherits from checkbox, so it can be applied to <input type=checkbox>.

<a href>, <button> (and the various input flavors of it), and <command> are the least specific commands. They are at the top of the role inheritance taxonomy, and so can be overridden by the widest range of roles. In addition, <a href>, and to a lesser extent <button>, are used to provide basic keyboard and AT access to functionality in pre-ARIA browsers, which provide basic active behavior for these elements. Their roles are implicitly overridden in these circumstances, and this proposal allows for ARIA to be used to make these overrides explicit.

This concept is embodied in the 8th of the Guiding factors for decisions on ARIA Role use:

8.Elements that have traditionally been overriden by authors have less restrictive role usage rules.

This technique allows authors to create content that is accessible in non-aria-supporting browsers, or ARIA-supporting browsers being used with non-ARIA-supporting AT, but which is progressively enhanced to use ARIA in browser/AT combinations that support it. It is necessary to use the native behavior of anchor links and buttons to expose the active nature of the content to the assistive technology. These browsers and AT support only the semantic of “clickable”, “active”, “does something”, and not the more complex semantics available in HTML 5 or ARIA. Writing this behavior in script, in the absence of ARIA, does not allow for any combination of browser and AT without ARIA support to interact with the content, and poses serious accessibility problems.

In order to provide ARIA-based content that degrades gracefully to these scenarios, it is necessary to build the UI as one would have before ARIA, out of links and buttons, and then over-ride those semantics with more specific ARIA semantics.

11.This concept is embodied in the 11th of the Guiding factors for decisions on ARIA Role use:

Where current authoring practices include overriding structural and interactive elements as the basis for progressively enhanced widgets, less restrictive role usage rules are allowed.

A command in HTML 5 is defined as "A command is the abstraction behind menu items, buttons, and links." The HTML 5 spec treats these all as related. HTML 5 commands are active elements -- they do something. Exactly what they do is somewhat flexible.

Elements that “define a command” in HTML include “An a element with an href attribute defines a command.” And “A button element always defines a command. The Type, ID, Label, Hint, Icon, Access Key, Hidden State, Checked State, and Action facets of the command are determined as for a elements.” The HTML 5 spec already treats these two elements as equivalent from a behavior perspective. In the context of a menu, both elements would be mapped to a platform accessibility API as menuitems. This proposal allows the same thing to be accomplished via ARIA.

Similarly, an input element of type checkbox can define a command when it is in the context of a menu.

An input element whose type attribute is in one of the Submit Button, Reset Button, Image Button, Button, Radio Button, or Checkbox states defines a command.

The Type of the command is "radio" if the type attribute is in the Radio Button state, "checkbox" if the type attribute is in the Checkbox state, and "command" otherwise.

When this happens, the role mapping the accessibility API can be expected to change to one appropriate for a checkable menu item. Allowing the ARIA role of menuitemcheckbox on an input accomplishes the same thing.

This concept is embodied in the 14th of the Guiding factors for decisions on ARIA Role use:

14.All elements that define a command can override their peers in the ARIA taxonomy tree. Commands are very similar to each other in HTML5, and real-world practice shows that the differences can be quite subtle. Many developers see a link and a button and a menu item as largely the same thing. HTML 5 and real-world use of ARIA reflect this.

basis for defining h1 to h6 element that does have an hgroup ancestor

Currently the spec does not mention what if any are the default roles for Hx elements inside a hgroup element. In the spec it is defined how the hgroup element takes on the heading level of the highest ranking Hx element inside the hgroup element. It is not logical or practical that the semantic information about both the heading elements contained within the hgroup and the hgroup itself is conveyed to assistive technology. After discussion on the HTML working group mailing list about what roles hgroup and Hx elements inside hgroup should have it is suggested that the hgroup element have no default role and that The first h1 to h6 element element with the highest ranking (1-6) has a heading role with the aria-level property set to the element's ranking . Any other h1 to h6 element elements have no default role.

Currently in the HTML5 specification the default roles for h1-h6 elements inside a hgroup element are not defined, this implies that all h1-h6 elements inside hgroup have no default role. The hgroup element is defined as having "heading role, with the aria-level property set to the element's outline depth". So for a given hgroup:

<hgroup>
<h2>Foo</h2>
<h3>Bar</h3>
</hgroup>

as currently defined the result would be:

<h2>
<p>Foo</p>
<p>Bar</p>
</h2>

This does not correctly convey the intended semantics and actually removes any distinction between the h2 and h3 content for the accessibility client users, whilst retaining the visual cues that indicate subheadingness for the sighted user.

The collorary of the current mapping is that any visual styling differences between the h2 and h3 should be removed for sighted users so that it looks like a single heading with multiple lines of text. there is no evidence of see this being suggested anywhere in the spec.

If the change proposals suggested mappings are used it results in something akin to:

<h2>Foo</h2>
<p>Bar</p>

Which better matches the semantics that hgroup is intended to convey. That is a heading with a subheading. It does not correctly convey the subheadingness of the h3 content, but that is due to the inherent failure of hgroup as currently specced to unambiguously indicate a subheading semantic.

For the purposes of a document outline the correct heading will be extracted.

Given that:

"There is (by definition) no difference between the headings in the "full page view" and the headings in the outline view."

For the purposes of in page viewing the text of the subheadings should have no default role as neither ARIA or HTML5 defines a "subheading" role. Ideally hgroup should be removed from HTML5 being replaced with an element defined as a subheading.

an alternative

An alternative is to not modify the heading semantics sent to accessibility APIs for headings inside hgroup, but provide advice in the spec about how AT should present the headings to users.

basis for changes to allowed roles on the a element

Currently the a element is defined in the HTML5 specification as an element that cannot have its native role overriden by ARIA roles. Developers have and will most probably continue to repurpose the a element to achieve desired interface features and style considerations using Javascript and CSS. While re-purposing the element may be non-conforming in HTML5, there is no indication to developers when using a conformance checker, because the changes that are made to make it non conforming cannot be checked using an automated conformance tool. So there is no reason to believe that as long as developers find a reason to repurpose the a element they will stop doing because it says so in the HTML specification. This view is confirmed by the author of the current ARIA in HTML5 conformance requirements:

"@cwilso I think we both know Web developers aren't going to be using the specs as a guide of what they can and can't use"

The use of ARIA in this case provides a way for developers to provide the same information about a custom control they have developed using the a element to assistive technology AT users that is available to everyone else.

Flagging the use of ARIA as a conformance error will most likely deter those people using conformance checkers from adding the ARIA attributes, while leaving an inaccessible control. The only people disadvantaged by the conformance requirements in the current spec are users with disabilities.

In some cases the addition of ARIA attributes, along with scripted behaviour and styling to elements when Javascript is supported, allows for graceful degredation of the content for when Javascript is not supported. This is an approach that should be encouraged not prohibited.

Examples of the a element being repurposed in popular JavaScript UI libraries:

basis for the img elements defualt role being img

<img> has been mapped to the MSAA role 'graphic' in IE since the the 1990s, and is the same in Firefox. AT products rely on this. There is not a compelling case here for breaking backward compatibility.

EVERY user agent that maps html elements to accessibility APIs, maps the <img> element to an image/graphic role in MSAA,IA2, ATK, UIA etc

HTML5 should not mandate UI for any user agents (it makes a point of not doing so for browsers. Not mapping <img> to role="img" will deny AT user agents the ability to offer users a preference about what role information they can receive since the img will become unidentifiable as an img.

basis for allowing roles on heading elements (H1-H6)

The heading elements for HTML continue to support scripting consequently any author can modify the use of H1-H6 to create an entirely new UI component. Even if this practice were stated to be non-conformant there is no way to prevent an author from doing this. It is perfectly valid HTML markup to use script on these elements.

Since we cannot prevent authors from modifying these elements we must have a vehicle to make them accessible so that the intent of the author is conveyed to assistive technologies from the markup. This is the premise behind the creation of WAI-ARIA. Furthermore, since these elements do not have any state or property information that would conflict with ARIA states and properties, unlike many of the standard form elements in HTML 5, any WAI-ARIA role, state or property is allowable.

Here an onclick handler is added to a header to launch an alert. This would be counter-intuitive to a header simply providing structural information to an an author.

<h1 onclick='alert("<h1> onclick!")'>Click to test</h1>

A blind user, when navigating, would only know that this is a header and would overlook the fact that the header responds to a user action. However, if the author were to indicate that the purpose of this element was to be a button:

Guiding factors for decisions on ARIA Role use:

It is more important for a user to be provided with name, role, property and state information which allows the users to successfully use the UI element as authored than it is for the user to be provided with what may be the misleading or less meaningful (in the context of use) default semantic information for an element.

Practical considerations of what is most likely to provide the most accessible experience for the user: The native semantic or the ARIA semantics.

In general text level elements do not have built-in UI behaviours or strong default semantics.

Composite form and interactive elements tend to have more built-in UI behaviours and stronger default semantics and therefore stricter role usage rules.

Elements that imports another resource into the document, or content from another vocabulary are considered in most cases to have strong native semantics.

Elements that have traditionally been overriden by authors have less restrictive role usage rules.

Elements with content that is not normally available to the users as part of the page are out of scope for the use of ARIA.

Where structural elements have been widely used for formatting and positioning purposes the use of role="presentation" is allowed.

Where current authoring practices include overriding structural and interactive elements as the basis for progressively enhanced widgets, less restrictive role usage rules are allowed.

When examining overrides within the structure or widget branches, we used the relationships in the ARIA taxonomy as a guide to allowable overrides.

Any element’s implied role could be overridden by roles that inherited from it in the taxonomy tree. For example, meuitemcheckbox inherits from checkbox, so it can be applied to <input type=checkbox>.

All elements that define a command can override their peers in the ARIA taxonomy tree. Commands are very similar to each other in HTML5, and real-world practice shows that the differences can be quite subtle. Many developers see a link and a button and a menu item as largely the same thing. HTML 5 and real-world use of ARIA reflect this.

We examined the results of the above effort, and removed any allowed overrides that didn’t make sense. In one case, we changed the structure of the ARIA role taxonomy to include a “command” branch, to more closely match HMTL semantics.

Details

h1 to h6 element that does have an hgroup ancestor: The first h1 to h6 element element with the highest ranking (1-6) has a heading role with the aria-level property set to the element's ranking . Any other h1 to h6 element elements have no default role. OR leave defaulkt heading semantics unchanged and provide advic to user agents on how to present the semantics of the heading/subheading.

Impact

Positive Effects

Authors will not be detered (by conformance error messages) from using ARIA to provide name, role and state information to AT users that matches the information provided to other users.

Developers will be able to use conformance checkers to check their code for correct syntax,values combinations etc of ARIA attributes providing an indication of whether they will actually work as per the ARIA spec, rather than to be told whether their use is prohibited by the HTML5 spec or not.