W3C home > Mailing lists > Public > w3c-wai-au@w3.org > October to December 2010

ATAG2 proposal on use of structure

From: Richards, Jan <jrichards@ocad.ca>
Date: Tue, 5 Oct 2010 18:28:25 -0400
To: AUWG <w3c-wai-au@w3.org>
Message-ID: <F2C77FB59A1A4840A01EF5F59B1826E20A2801AFF2@ocadmail.ocad.ca>
Hi all,

I had an action to propose a way to handle the comments on A.3.4.1 and A.3.4.2:

After a lot of thinking about what it is that we really want (more efficient navigation for slow-keyboarding users) I'm considering a new tack based on "programmatic relationships". This seems to me to be the most important kind of structure in terms of facilitating navigation:

A.3.4.1 Navigation of Programmatic Relationships: If an editing-view lets authors edit programmatic relationships within web content, then mechanisms are provided supporting navigation between the related content. (Level AA)
Note: Depending on the web content technology and the nature of the authoring tool, relationships can include element nesting, headings, labelling, programmatic definitions, ID relationships, etc.

Ed. Notes:
- I moved the navigation SC to AA because there are enough examples of editing being possible without structural navigation that they didn't seem "essential".
- I tried a lot of formulations of structural element along the lines of what was suggested " Not all markup elements are structural. A button is not a structural element. Structural elements are those that define structure for other content elements: landmarks, tables, headings, listboxes, lists, tree widgets, etc. Structural elements provide context in a defined layout or order. An example would be a containment model." But I couldn't get it to work because it's so context sensitive.
- We let the tool UI dictate which programmatic relationships are available. So a plain text field that was never intended to be used to create structured content, doesn't need to support any structural navigation.
- This covers great features such as many IDE's "Definition" that immediately finds the code behind a method call (which wasn't covered by earlier structure-based SCs).
- for flexibility it doesn't say how many mechanisms

(Mr) Jan Richards, M.Sc.
jrichards@ocad.ca | 416-977-6000 ext. 3957 | fax: 416-977-9844
Inclusive Design Research Centre (IDRC) | http://inclusivedesign.ca/
Faculty of Design | OCAD University
Received on Tuesday, 5 October 2010 22:30:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:39:59 UTC