Re: Using ARIA in HTML

Steve Faulkner, Fri, 29 Jun 2012 13:23:12 +0100:
> I have posted an intial draft of a document I have been working on 
> which attempts to provide practical advice to developers on what ARIA 
> to use in HTML.
> 
> http://dvcs.w3.org/hg/aria-unofficial/raw-file/tip/index.html

I found the table hard to read and the first principle unclear. So I 
made soem notes about how to fix:

1) May be the first principle etc should appear before the table
   instead of appearing in a post scriptum with the title "note"?

2) Amend the first principle like this, where the new or replaced
   words are _underlined_: [1]

   "If you can use a native HTML _feature_ instead of
    _adding_ an ARIA _attribute_, then do so."

   Justification: Less jargonistic language. And reuse of
   language used elsewhere in the document (especially if
   you implement my proposals below).

3) The table is hard to grasp.
   * please add shorter and clearer column titles:
    'Native HTML feature' (Now: 'Language feature')
    'Equivalent ARIA feature' (Now: 'default implied ARIA semantics')
    'Rely on native HTML feature?' (Now: Use default ARIA semantics?)
    'Alternative non-equivalent ARIA feature(s)' (Now: 'What Other ARIA
     roles, states and properties may be used?')
   * Replace NO with YES.
   * Replace YES with NO
     The above changes will cause the table to say "YES" when the 
     author should rely on the native HTML feature. It is best to
     express what authors should do (namely: nothing) using a positive
     YES. After all, this is one of the important messages of the doc.
   * In the last column, perhaps list the ARIA options in a list instead
     of just separating them with a comma?
   * Many of the "N/A" options should be changed to YES. Justification:
     Take for instance the HTML feature 'table' which has no equivalent
     ARIA feature. Here the message should be "YES, rely on the native
     HTML feature" (which AT supports very well, despite the lack of
     ARIA equivalent feature)
   * Exemplifying the table changes proposed above:

Native HTML f|Equiv ARIA f|Rely on native HTML f?|Alt. non-equiv ARIA f.
-------------|------------|----------------------|----------------------
    table    |    none    |          YES         | # roles: any,HOWEVER:
             |            |                      | ## only grid recc'ed
             |            |                      | ## presentation unrec
             |            |                      | # aria-*: global

   Table critique continues:
   * The point with the second row is to say that role=presentation is
     permitted on any element. However, the row is very hard to
     grasp. And strictly speaking, given the 'first principle', then
     there are several HTML features which have a native presentation
     role. So shouldn't authors use the these features, primarily,
     rather than changing the role of another feature to presentation?
-- 
Leif Halvard Silli

Received on Saturday, 30 June 2012 13:52:09 UTC