This is not a spec and has not been endorsed by anyone.

Introduction

A week ago, I wrote a draft document and an accompanying email about integrating ARIA into HTML5 from the point of view of document conformance. I have gotten only one reply so far (almost Warnocked), so I figured I’d go ahead and implement my suggestions in order to produce something people can actually try. This document describes the implementation deployed at Validator.nu as of 2008-03-31.

The implementation is based on schemas written in RELAX NG and Schematron. DTDs, XSD, OWL or RDF Schema are not involved in any way.

HTML-isms in Attribute Values

When an attribute takes one of enumerated possible valid values, whitespace around the token is not allowed. The role attribute is considered to take an enumerated token value. (Now is not the time to cross the ARIA 2.0 extensibility bridge on the validation side.)

Enumerated values are not case-insensitive, however. They must be in lower case.

Numeric values use HTML5 microsyntaxes instead of XSD datatypes.

State and Property Groups for Implicit Roles

I identified the following implicit roles.

aria.implicit.button

aria-controls

aria.implicit.input

aria-controls, aria-invalid, aria-required

aria.implicit.region

aria-atomic, aria-busy, aria-channel, aria-controls, aria-expanded, aria-live, aria-relevant

aria.implicit.group

aria-atomic, aria-busy, aria-channel, aria-controls, aria-expanded, aria-live, aria-relevant, aria-activedescendant

aria.implicit.th

aria-sort, aria-atomic, aria-busy, aria-channel, aria-controls, aria-disabled, aria-expanded, aria-live, aria-readonly, aria-relevant, aria-selected

aria.implicit.structure

aria-atomic, aria-busy, aria-channel, aria-live, aria-relevant

aria.implicit.link

aria-controls, aria-disabled

aria.implicit.listitem

aria-posinset, aria-setsize, aria-atomic, aria-busy, aria-channel, aria-live, aria-relevant

aria.implicit.img

aria-atomic, aria-busy, aria-channel, aria-controls, aria-live, aria-relevant

aria.implicit.select

aria-invalid, aria-required, aria-atomic, aria-busy, aria-channel, aria-controls, aria-live, aria-relevant

Unsupported Roles

The following roles are unsupported. The first four duplicate ancient HTML 4.01 built-in semantics. Landmarks mostly duplicate HTML5 container elements.

• rowheader
• columnheader
• document
• heading
• Landmarks

Unsupported States and Properties

The following states and properties are not supported. (Links to rationale.)

• datatype
• level
• hidden
• owns
• templateid

Unsupported Requirements

The use of the group role is not properly specified. Moreover, an informative example in the spec and sample code from the University of Illinois disagree. Using group in trees or lists is not supported.

tab and tablist containment lacks reciprocity in the spec, so the validator only checks that the parent of a tab is tablist but checking for non-tab children of tablist is not supported.

Some grid-related containment rules are not checked, because I’m hopeful that the spec will change to use the natural structure of an HTML table.

The containment relationship of directory and link seems too strict and is not checked.

“Accessible Name Required” rules are not supported, because I didn’t get around to reviewing and implementing them yet.

Special—No Role Allowed

These elements do not accept a role attribute due to being special in some way.

• area
• base
• bdo
• br
• col
• colgroup
• datatemplate
• embed (plug-in should be itself accessible)
• event-source
• head
• input type=hidden
• link
• map
• meta
• nest
• noscript
• param
• rule
• script
• source
• style
• thead
• tfoot
• tbody
• title
• html

Strong Native Role—No Override

The following elements have strong native semantics and to dissuade authors from overriding these native semantics, the following elements do not accept a role attribute. However, some of them accept states and properties according to the implicit role.

Handling button analogously with button input.

Weak Native Role—Override Allowed

The following elements have an implicit role and accept states and properties according to that role. However, the native role can be overridden with the role attribute.

No Native Role—Any Role Allowed

The following elements have no states and properties by default but can accept any role using the role attribute.

• abbr
• b
• blockquote
• canvas
• cite
• code
• dd
• dfn
• div
• dl
• dt
• em
• font
• i
• img
• kbd
• object
• p
• pre
• q
• samp
• small
• span
• strong
• table
• td
• tr
• var

Findings So Far

To find out how far out these made-up rules are from what people expect to do with ARIA, I validated the University of Illinois ARIA examples.

• A grid example turns table headers into buttons. This is problematic, because the aria-sort property does not apply to buttons. It seems to be it would make more sense not to override the native semantics of th and indicate that the headers can be clicked to sort by setting focusability with tabindex.

• The live region states and properties are used without an explicit role on span. Perhaps it would make sense to move the live region states and properties to global states and properties.

• The parent—child requirements (from the ARIA spec—not made up by me) are not always followed. Here menuitems do not have a menu parent. Also, validating seems potentially useful by revealing an accidental aria- prefix in a role value. (This demo does not work for me visually in Firefox 3b4, by the way.)

• Another case where a validator could help. Is “descendant” too prone to get misspelt? “labelled” is even noted as problematic in the spec.

• Of the states and properties I opted not to support in this draft, aria-hidden is actually used by the demos. Is it too late for irrelevant? On the other hand, the other states and properties that I opted to support are ones that were not used in the demos.

• Leaving group partially unsupported did hit a demo case, though.

Changelog

1. Made input type=image overridable
2. Swapped the specialness of html and body