1.1 The Problem

Aspects of traditional Hypertext Markup Language (HTML) make accessible support of dynamic content difficult:

  1. Accessibility of dynamic content relies on abstracting semantics from both content and presentational information. Extracting semantic cues from current HTML content is typically unreliable as the cues are limited to tag elements names. [Accessibility of static content depends on a the ability to ignor style information. ]
  2. HTML allows content to be repurposed for presentational formatting without providing a way to convey semantic information. A common example of this is content formatted with tables rather than style sheets. [This is true, buy why deoes it motivate a need for ARIA? It just neccessitates accessible vanilla html. Maybe 2 and 4 should be combined or linked somehow. ]
  3. When combined with script and cascading style sheets (CSS), HTML can be repurposed to create dynamic custom components without providing a means to convey semantic information to native accessibility architectures designed to support dynamic graphical user interface (GUI) content.
  4. HTML lacks the ability to attach meaningful metadata about document structure.
  5. HTML elements commonly used for repurposing produce custom components that are not keyboard accessible.

[This is important but non sequitur ]Authors of JavaScript-generated content do not want to limit themselves to using standard tag elements that define the actual user interface element such as tables, ordered lists, etc. Rather, they make extensive use of elements such as DIV tags in which they dynamically apply a user interface (UI) through the use of style sheets and dynamic content changes. HTML DIV tags provide no semantic information. For example, authors may define a DIV as the start of a pop-up menu or even an ordered list. However, no HTML mechanism exists to:

...

.....

1.3 Solution

What is clear from the problem statement is that the author [of dynamic content? of this document? ] does not have the ability to provide the appropriate accessibility information in the markup to support the accessibility APIs on the target platform. This problem is not limited to HTML. It extends to other markup, including Scaleable Vector Graphics [SVG]. This primer addresses the problem for web content delivered to desktop browsers and introduces you to common extensions to both HTML and XHTML called Accessible Rich Internet Applications (WAI-ARIA) Version 1.0 [ARIA]. The goal is to make these standard features in HTML 5.

2 Filling the Gaps for Content Delivered to Desktop Browsers

At this time, the primary effort in the W3C WAI Protocols and Formats working group is to focus on extensions to HTML 4.01 and XHTML 1.X by extending the host language to include W3C ARIA with a migration path to HTML 5. [It appears that ARIA adds methods to static HTML elements creating OOP objects. Why will this need stop with HTML 5? Won't people always want to extend semantics to special DIV elements or create sub-class behavior methods for HTML 5 Elements? ] This will require the creation of new hybrid document type definitions (DTDs) that incorporate the extensions. ....

.....

[What is a role How does this apply to dynamic applications in web pages? Role is never defined in the Overview and not here, even informally. We must say something as plain as ''the role is a standard GUI application that is recognized by standard accessible API's". Maybe a little more accurate, but that level of plain soeecg. I understand this document as transitional from the "Overview" to very technical documents. This and the next section jump too far and too fast. I am very embarrased to say that it took me a month to figure out what a role was within this context (maybe I understand). ]

Role attribute - The role attribute, borrowed from the, XHTML Role Attribute Module [XHTML-ROLES], allows the author to annotate host languages with machine-extractable semantic information about the purpose of an element. It is targeted for accessibility, device adaptation, server-side processing, and complex data description. ARIA uses the role attribute to provides the role information, in Figure 2 - Accessibility Interoperability at a DOM node with JavaScript to an assistive technology.

Role document landmark values - These values, borrowed from the XHTML Role Attribute Module [XHTML-ROLES] provides a standard set of role attribute values designed to define pertinent parts of a document (landmarks) for the purpose of accessibility. User agents may incorporate device equivalents, such as key mappings in the case of a desktop user agent, to navigate to these sections of a document.

Taxonomy of ARIA role values - The necessary core roles found in Accessibility API sets for Windows and Linux as well as roles representative of document structure. [Some examples are necessary.]

...

2.1 Use of New Provisions for Keyboard Focus and Semantics to Support Platform Accessibility APIs

[Again this is vital information, but the transition is too steep from the overview. I like this section. ]Adaptive technologies, which need to provide alternative access to complex user interfaces authored via HTML, are often left guessing at the semantics behind specific portions of HTML document. As an example, an XHTML document might use a certain HTML construct, such as a collection of DIV tags, to create navigation bars, a site-navigation menu, and other GUI-like user interface widgets. To fix the problem, we incorporate the role attribute, assign the accessible state properties, and give the object focus using the new TABINDEX feature. Addition of this information helps authors to provide the necessary information to enable the user agent to support the accessibility API accessed by the adaptive technology.

​

2.1.1 Provision of the Role Attribute: "What is the Object?"

[Does this need to move up?] Each platform accessibility API has the notion of a "role" for a GUI object. This is the case for Java Accessibility API [JAPI], Microsoft Active Accessibility [MSAA], Apple Accessibility for COCOA [AAC], and the Gnome Accessibility Toolkit (ATK) [ATK], or UI Automation for Longhorn [UIAUTOMATION] (called content type in UI Automation). The W3C ARIA specifications are based on XHTML 1.X and include the role attribute. The "role" attribute takes a qname, enabling authors to reference the role attribute from the ARIA Roles. In the following example, we use qname to reference the menu role in the WAI-ARIA specification.

.....

The HTML working group decided to make role a qname and allow others to define sets of standard roles. Furthermore, these roles should be extensible. It is the intent of the HTML working group to have these qnames refer to RDF, which defines the element. ... [Does the ARIA really mean to say that ARIA is a just a stop gap for HTML 5 ? ]

​

2.1.2 Provision of the Accessibility State Information: "What meaningful properties does this object have at this time?"

Since this is dynamic content, the state of these new repurposed objects will change. The WAI-ARIA specification shall provide the common accessible properties needed to support the accessible state or property information provided by the platform accessibility API defined previously. This specification was created based on an analysis of the accessibility properties defined in MSAA and ATK. To pull in this information we again use namespaces to extend XHTML. The following example extends the previous approach by adding the haspopup accessibility property. [HTML doesn't have namespaces. How does this work for HTML? ]

...

​

2.1.4 Supporting ARIA in XHTML and HTML 4.01

Unlike XHTML, HTML 4.01 is non-extensible in that it is not possible to extend HTML 4 through the use of namespaces. That said, members of the working group have worked with the HTML working group to agree on a vehicle that does not use namespaces, which at this time is supported by XHTML and HTML which will be supported in HTML 5 when it becomes recommendation. Firefox 3 is leading the way to implement this, and other browser manufacturers are working to support it as well. The technique allows all role values specified in ARIA (including those specified by the XHTML Role attribute module) to be specified without a namespace prefix. Additionally, ARIA states and properties shall be represented as aria- followed by the concatenated ARIA state or property. [This a good arguement against continuing with HTML. ]

...

2.2 Use of XHTML Role Landmarks to Improve Document Navigation

[Very nice. Section ]

...

​

2.3 WAI-ARIA Role Taxonomy - Extensible Semantic Role Model, using RDF/OWL

[I suggested a modified (verbose) RDF to expres this picture in words. I stil think it is needed for accessibility. Michael Cooper created a first try that he rejected. But, we need something. There is too much meaning in this figure to skip it. The representatin as a directed graph conveys precise meaning in which direction is not conveyed in the description paragraph. ]

​ Sample Semantic Map for Taxonomy
Figure 4.0 Example, Partial RDF Map for a possible ButtonUndo role as an extended role to ARIA

 

[Nice section... ]

 

Figure 4.0 shows a basic RDF mapping that defines a set of terms and relationships defining an object. At the center is a Widget object that defines common states and properties for all GUI widgets. ...

...

[Out of Gas for Now! ]