W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 2010

ACTION-445 Redraft proposal for 2.1.4

From: Greg Lowney <gcl-0039@access-research.org>
Date: Thu, 02 Sep 2010 14:57:41 -0800
Message-ID: <4C802BE5.8070800@access-research.org>
To: WAI-UA list <w3c-wai-ua@w3.org>
  Here is my proposed revision to the Intent and Example for 2.1.4 (Programmatic Availability of DOMs), incorporating the feedback I included on the survey at http://www.w3.org/2002/09/wbs/36791/20100802-3/results#xq4. (ACTION-445 <http://www.w3.org/WAI/UA/tracker/actions/445>  incorrectly lists this as being about 2.1.5, but it's really about 2.1.4.)

2.1.4 Programmatic Availability of DOMs: If the user agent implements one or more DOMs, they must be made programmatically available to assistive technologies. (Level A)

.    Intent of Success Criterion 2.1.4:

Assistive technologies often use a combination of methods to get information about and manipulate an application and its content. These methods include platform accessibility APIs (such as MSAA or JAA), general-purpose platform APIs (such as those used to determine a window's title), application-specific APIs (typically a last resort when an application does not make all information available through the former means), DOMs, and hard-coded heuristics. It is the user agent's responsibility to make the necessary information and facilities available through the appropriate corresponding means. Because DOMs typically provide capabilities that are fine-tuned to a specific content type, and therefore far richer than the other methods, exposing DOMs to assistive technology is an extremely important part of AT compatibility. This complements, but does not replace, the need to support other methods, such as platform accessibility API, because although they are less powerful, they 
allow assistive technology to work with a wider range of applications.

Examples of Success Criterion 2.1.4 :

o    Kasandra is using a screen reader as she browses the Web. When a sentence is read to her, she suspects that some of it might be in italics, so asks the screen reader to read it aloud indicating changes in font. Because font information is not included in the platform accessibility API, the screen reader accesses the DOM exposed by the browser, and from that is able to determine which phrases are italicized, bolded, and so forth.

o    Daina is using a screen reader with her web browser and views a Web page containing HTML, MathML, and SVG, each of which has a separate DOM. When she asks her screen magnifier to display the document as a single stream of large print text, it is able to ask the browser for access to the main (HTML) DOM and the individual DOMs for the nested MathML and SVG. It then walks through all three DOMs and combines in order to extract their content and present it in way that is seamless to her.

     Thanks,
     Greg
Received on Thursday, 2 September 2010 21:58:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:39 UTC