should WAI-ARIA 1.0 have a distinguished 'help' (or equivalent) role for how-to context help [ARIA 1.0]

** background / on the process

Doug Schepers, the Team Contact from SVG WG had an idea based on  
their design work
for SVG Tiny 1.2.  Note that this is rather mature, and will likely  
advance up the
Rec track ahead of WAI-ARIA.

http://lists.w3.org/Archives/Public/public-pfwg-comments/2008JulSep/ 
0018.html

I have opened up an issue for consideration by the Working Group  
because he was not
satisfied with the response he got from one of our Participants.

This is ISSUE-75 http://www.w3.org/WAI/PF/Group/track/issues/75 --  
Member-confidential link.

Please discuss this issue on wai-xtech@w3.org because it involves  
issues of interest
to UAAG and WCAG, and because SVG WG works in public.

*** summary

please review the pro and con discussed below

Next step options include

* SVG coins new element
* SVG coins new role value (for definition in SVG), requests comment  
from XHTML2 and PFWG.
* PFWG adds new document role

*** rambles / on the product

** arguments pro

* context help use case is endemic

Ever since the U.S. Social Security Administration went to Freedom  
Scientific and got
them to recognize a non-standard @contexthelp attribute, I have  
considered it a priority
for us to have a good solution for context help.

* improves author comprehension

Various of our document roles are not essential for the API binding,  
rather being
a heuristic hint or aid to the author.  In particular "description"  
is in this category.
The essential information is captured in the @aria-describedby arc  
pointing at the
element containing the description.  The @role='description' adds no  
new information,
it does help the author keep straight what they are doing there.

* style guide makes this distinction

The keyboard command vocabulary recommended by our friends in the  
Style Guide caucus
distinguishes popup or baloon ask-for help from general onMouseOver- 
appearing content.

http://dev.aol.com/dhtml_style_guide#popuphelp

** arguments con

* little red hen

There is no need for SVG to be dependent on a @role value introduced  
in the WAI-ARIA spec
to denote the intended semantic distinction (this is about how-to  
content, not about
onMouseOver behavior).  SVG can just do it themselves without  
depending on PFWG action.

There are a variety of ways that SVG could just do it themselves.  An  
element type,
a role value, or otherwise.

SVG can coin a <help> or <contexthelp> element in SVG that has SVG- 
specified behavior.
See the Style Guide for currently proposed command profile for this  
function

http://dev.aol.com/dhtml_style_guide#popuphelp

SVG could propose to define a value for @role.  This would be a  
document role, it is
not in contention with the PFWG-controlled widget roles.  So far the  
XHTML2 and PFWG working
groups are the two in the community adding role names to this  
vocabulary, but there
is no golden rule that says we should own it.  I would argue with  
PFWG and XHTML2
that we should invite SVG to join the swim and coordinate additional  
terms there
as required.  [But I think an element name is here a better solution].

In other words, while you have the host-language format open for  
editing, don't
defer to an @role value semantics that you can do in the native  
markup of the langugage.

Just as PFWG decided to mirror the <html5:article> semantics in a  
role symbol, we
could eventually see the wisdom of your ways and add such a role for  
use of the same
semantic in other host languages.

A related argument for SVG to do this in SVG rather than in WAI-ARIA  
is because of the
order of maturity.

* general semantics later

We recognized early that although metadata can be introduced by  
attributes linking
to RDF, and that all kinds of metadata could be handy in deriving  
adapted user experiences,
that for 1.0 we were going to include those things necessary for the  
user to (a)
understand how to operate the scripted behavior and (b) understand  
how to navigate
the pages containing the scripted behavior.

Roles for every purpose notion that one could imagine was clearly  
going to bloat
ARIA beyond what we could finish and publish.  So we deferred role  
extension and
general semantic annotation beyond WAI-ARIA 1.0.  One could argue  
that the distinction
between context help and random popup content (given that the popup  
behavior and
how to get to the information with the keyboard is covered by the  
@aria-haspopup
semantics) is general semantics not meeting this test for inclusion  
in WAI-ARIA 1.0.

*** please discuss

Al

Received on Tuesday, 9 September 2008 18:04:54 UTC