[Bug 25140] restrict summary element content?

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

--- Comment #5 from steve faulkner <faulkner.steve@gmail.com> ---
(In reply to Simon Pieters from comment #4)
> (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?

problems include:

unclear how accessible name from <summary> is bound to anonymous control in
shadow dom?

If the summary element continues to be allowed to include controls how is a
useful accessible name to be calculated?
e.g.

<summary> major pain <input type=checkbox> also show minor pain (max number of
minor pains <input type=number>) </summary> 



> 
> > 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?

they don't, but that does not mean we should replicate OS X poor ui.

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

sure, asking to increase the size so it is a usable for people with fine motor
skill impairments is an ask that will often not be met. having the summary
element represent the click area by default = built in 
usability/accessibility.

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

Received on Tuesday, 1 April 2014 10:23:55 UTC