[Bug 25140] restrict summary element content?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25140

--- Comment #4 from Simon Pieters <simonp@opera.com> ---
(In reply to steve faulkner from comment #3)
> thanks, its difficult to tell from the screenshots alone whether the usage
> represent reasonable use cases or not.

Yeah, I picked things from a Google Image search for 'form disclosure triangle'
(or some such), I'm not confident all of them are valid.

> One thing I noted was in the example
> http://i.msdn.microsoft.com/dynimg/IC115703.png there is a focus rectangle
> around the auto updating 'summary'. I had a look at the interface in 8.1 and
> found that the whole 'summary' is clickable and exposed as a button in acc
> APIs.

OK.

> Currently I think the control aspect of details/summary is underspecified as
> there is no method to provide an accessible name (LABEL)for the 'anonymous
> control' that allows operation of the widget. whereas the accessibility
> implementation example provided in the HTML acc API spec [1] does provide 
> clear advice.

If the triangle needs an accessible name, can't it get the accessible name from
the summary element?

> Also from an accessibility/usability perspective having the summary element
> as the actionable control provides a large activation area, as does the
> current (seemingly) broken implementations. 
> 
> thus the suggestion in this bug to restrict the content allowed in summary.
> 
> Do you see a way the specification of the summary/details element can be
> improved to both allow nested controls and provide a clear method to
> associate a visible label, with a large enough click area to accommodate
> accessibility/usability requriements?

How does e.g. OS X solve the large click area requirement?

The triangle's click area doesn't need to be small, per spec, AFAICT.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 28 March 2014 12:06:57 UTC