W3C home > Mailing lists > Public > public-html@w3.org > September 2010

ARIA mapping status update

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 16 Sep 2010 01:09:44 -0700
Message-id: <044123B7-3CD0-42A9-80B6-08190C34AE3C@apple.com>
To: HTML WG <public-html@w3.org>

Recently I sent a status update on ARIA-related bugs against HTML5, in the interests of informing the group and helping to expedite work. Here is another update. Thee are a number of new bugs since last week.


- 15 points of agreement (apparent consensus)
- 5 clear point of disagreement (escalated)
- 3 items with next action on proposal authors
- 12 items with next action on editor
- 1 item with next action on PFWG
- 1 other

= No Action Needed; consensus found =

'math should be changed changed from no role to "math" role'
 -> RESOLVED WONTFIX; A11Y TF proposal has been updated to match

'<input type=file> has "button" role, but is typically a compound control'

'menu type=context should have "menu" role'
  -> RESOLVED WONTFIX; A11 TF proposal has been updated to match

'<link> that represents a hyperlink should probably have no role by default'
  -> RESOLVED WONTFIX; A11 TF proposal has been updated to match

'ARIA section does not list elements that have no default role or role restrictions'

'Certain elements with no role should have that as a strong semantic'

'Consider limiting the roles of certain media and plugin elements'
 -> RESOLVED FIXED (partial fix, but A11Y TF proposal is already updated for the difference)

'Consider restricting the roles allowed for the label element'

'provide correct aria mapping and role info for the table element'

'The img element with non-empty alt should default to the img aria role'

'References to "image" ARIA role should be "img"'

'Allow radio buttons and checkboxes to be used as radio and check menu items respectively'

'fix error in aria conformance checker advice'

'provide a comprehensive HTML5 to accessibility API mapping reference'
 -> RESOLVED WONTFIX -- note, this requests a spec change that is not reflected in the proposal. Discussion on the list seems to indicate it won't be pursued further.

'modify aria example and fix spelling;

= No Action Needed; disagreement has been escalated =

'ARIA roles added to the a element should be conforming in HTML5'

'"ARIA restricts usage of this role to one per page" is an unclear statement'

'<output> should have a status role by default after all
 -> RESOLVED FIXED -- this was reversed from the original request by consensus of A11Y folks; has been updated in the A11Y TF proposal

'Consider broadening the set of allowed roles for command elements'
 -> RESOLVED WONTFIX -- this seems like a philosophical difference at this point so maybe reopening more is not the best course

'merge ARIA mapping tables and list'
 -> RESOLVED WONTFIX (again, it seems like a matter of style how the different tables are broken down, so maybe we can let this one slide)

= Next Action on Proposal Authors =

For most of these, the editor has fully or partially rejected a portion of the proposal, with a stated rationale. For each of these, the proposal authors should take one of the following actions:
- If they agree with the rationale given, then please update the proposal to match.
- If they have relevant new information which should be given fresh consideration by the editor, then reopen the bug (but please don't chain-reopen too many times).
- If there is a clear point of disagreement, then mark it TrackerRequest. We can roll all these up into one tracker issue.

'Consider documenting attributes that map to ARIA properties in a separate table'
 -> RESOLVED WONTFIX (as a side note, it seems like a matter of style how the different tables are broken down, so maybe we can let this one slide)

'provide headings in the WAI-ARIA section of the spec to make it easier to understand'
 -> RESOLVED WONTFIX (seems purely an editorial matter again; is this really important?)

details element
 -> no bug on this, but proposal authors agreed that what is in spec generally makes sense; proposal needs updating

= Next Action on Editor =

'Details element Focus problem

'add role=radiogroup to details element'
 -> reopened; needs new response from editor

'consider allowing various command-like ARIA roles for h1-h6'

'Allow lists to be used as menus or tab sets' -- partially accepted except for presentation role - extra motivation provided for that specifically

'conflicting info for table element in aria section'
-> NEW

'"h1 to h6 element that does have an hgroup ancestor" not listed in ARIA section'
-> NEW

'thead, tfoot and tbody conflicts in aria section'
-> NEW

'conforming use of various aria attributes not specified
-> NEW

'Strong semantics role="presentation" for <img alt="<empty>"> is wrong or inaccurate'
-> NEW

'Clarify what default roles UAs may assign to elements not listed in the ARIA section'
-> NEW

'Clarify what <img role=presentation alt=<not-the-empty-string> > means'
-> NEW

'Use "unmapped" rather than "no role" in the weak/strong ARIA tables'
-> NEW

= Next Action on PFWG =

'modify table, tr and td roles'
 -> RESOLVED WONTFIX -- there seems to be a dispute over what the ARIA spec says here and what it should say; no consensus even among PWFWG members.
 -> I have submitted a comment to PFWG which sparked a thread: <http://lists.w3.org/Archives/Public/public-pfwg-comments/2010JulSep/0029.html>

= Other =

'provide clear user friendly links to WAI-ARIA documents in the ARIA section of the spec'
 -> RESOLVED LATER -- editor proposes to do this later using an automatic cross-reference tool. Strikes me as reasonable.
Received on Thursday, 16 September 2010 08:10:18 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:25:50 UTC