2.5.3 Location in Hierarchy

Hi! As we've discussed before, one of my main problems with the current 2.5.3 is that it's written in a very technical, jargon-rich style that makes it confusing to some readers (including me). Here's an attempt to simplify the wording, while keeping the meaning essentially the same. I've also added draft Intent and Examples. As it is, I'm not sure I can justify making it Level A; I've tentatively reduced it to AA, but that's certainly up for discussion.

Existing wording:

    *2.5.3 Location in Hierarchy: *The user can view the path of nodes leading from the root of any content hierarchy in which the structure and semantics are implied by presentation, as opposed to an explicit logical structure with defined semantics (such as the HTML5 Canvas Element), or as a consequence of decentralized-extensibility (such as the HTML5 item / itemprop microdata elements), and only if the user agent keeps an internal model of the hierarchy that it does not expose via the DOM <http://www.w3.org/WAI/UA/2012/ED-UAAG20-20120815/#def-dom> or some other accessibility mechanism. (Level A)


Proposed rewording:

    *2.5.3 Location in Hierarchy: *When the user agent is presenting hierarchical information, but the hierarchy is not reflected in a standardized fashion in the DOM or platform accessibility services, the user can view the path of nodes leading from the root of the hierarchy to a specified element. (Level AA)

    Intent:

        Many users rely on assistive technology to interpret information displayed on the screen and convey it to them different ways. Sometimes when a user agent displays different pieces of information on the screen it understands relationships between them that can't easily be conveyed through either the DOM or platform accessibility services, making it difficult or impossible for the assistive technology to infer and interpret. In these cases the user agent should provide the ability to present those relationships in a simplified way that can be understood by the assistive technology, and by users who have difficulty interpreting complex visual presentations.

        This is also required when the hierarchy is included in the DOM but in a non-standardized fashion, such as using proprietary attributes or distributed extensibility microdata, because such proprietary information would not be useful to assistive technology.


    Examples:

        Armand is blind, and his media player uses an XML data structure that describes each audio piece in terms of genre, artist, album, and track. It displays columns for each of those categories, where he can select one entry in order to filter the contents displayed in the subsequent columns (e.g. he selects one entry in the Artist column, causing the Albums and Tracks columns to only show items associated with the selected artist). The user agent understands the hierarchical nature of these columns, but as they that cannot be conveyed in the HTML used for presentation, they are not in the DOM for access by his screen reader. Therefore, when Armand moves the focus to an item in the Tracks column, the user agent updates a static text field that shows the path of genre, artist, and album associated with the track, and Armand can have this field read to him, either on request or automatically when it updates.

Thanks,
Greg