- From: <bugzilla@jessica.w3.org>
- Date: Thu, 27 May 2010 18:01:32 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9817 Summary: Details element Focus problem Product: HTML WG Version: unspecified Platform: All URL: http://dev.w3.org/html5/spec/interactive-elements.html #the-details-element 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"> ... </details> In this scenario the open attribute would have implied semantics equivalent to aria-expanded 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 it. 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 patterns. -- 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