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

[Bug 9817] New: Details element Focus problem

From: <bugzilla@jessica.w3.org>
Date: Thu, 27 May 2010 18:01:32 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-9817-2486@http.www.w3.org/Bugs/Public/>

           Summary: Details element Focus problem
           Product: HTML WG
           Version: unspecified
          Platform: All
               URL: http://dev.w3.org/html5/spec/interactive-elements.html
        OS/Version: All
            Status: NEW
          Keywords: a11y
          Severity: blocker
          Priority: P1
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: schwer@us.ibm.com
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html@w3.org

Both the summary element and the details element are capable of receiving
focus. That is problematic for assistive technologies. It would mean that the
author could give the container focus <details> and the <summary> element
focus. That is incredibly confusing as you have two elements meant to represent
the entire element. 

So, if details gets focus we would need to say that the implied semantics is a
something like:

<details role="button" aria-labelledby="sumid">
<summary id="sumid">

In this scenario the open attribute would have implied semantics equivalent to

If you want summary to have focus then we have to give it a role of button with
an aria-expanded property. That does not make a lot of sense but we could do

If both summary and details have focus it is a pain for browser manufacturers
and ATs requiring special case software to handle two different design

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 Thursday, 27 May 2010 18:01:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:17 UTC