[Bug 10424] New: Permit <details> to take "roles that use the aria-expanded state"

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10424

           Summary: Permit <details> to take "roles that use the
                    aria-expanded state"
           Product: HTML WG
           Version: unspecified
          Platform: Other
               URL: http://www.whatwg.org/specs/web-apps/current-work/#ann
                    otations-for-assistive-technology-products-(aria)
        OS/Version: other
            Status: NEW
          Keywords: a11y, aria
          Severity: normal
          Priority: P3
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: xn--mlform-iua@xn--mlform-iua.no
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html@w3.org


REQUEST: clarify that <details> can take _all_ roles that use the aria-expanded
state.

Bug 9623 added strong semantics to <details> by linking presence/absence of the
@open attribute to the aria-expanded="true/false" state. The new spec text
says:

]]
(The role can be changed as described in the next table, but is restricted to
roles that use the aria-expanded state.)
[[

But the above sentence is unclear: Is it the _complete_ subset of "roles that
use the aria-expanded state" that makes up the permitted roles? Or is it "the
next table" that decides? The list in "the next table" anyhow permits only a
subset-of-the-subset of roles that use the aria-expanded state:

]]
Role must be either form, group, navigation, note, or search
[[

Thus the table e.g. forbids <details role="img" >. Despite that role="img"
_does_ use the aria-expanded state. 

It is unclear whether "the second table" simply fails to list all the roles
that use the aria-expanded state. Or whether the spec simply fails to describe
the principles/criteria behind the selection of permitted roles.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 25 August 2010 01:54:20 UTC