[Bug 25140] restrict summary element content?

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

--- Comment #6 from Simon Pieters <simonp@opera.com> ---
(In reply to steve faulkner from comment #5)
> problems include:
> 
> unclear how accessible name from <summary> is bound to anonymous control in
> shadow dom?

I'm not entirely familiar with either the accessibility stuff or shadow DOM,
but I don't see why it would be problematic to define in the spec that the
anonymous control gets its accessible name from the <summary>. The UA knows how
to get from one to the other since it's needed for open/close to work.

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

Just calculate the accessible name using the generic rules to calculate an
accessible name for an element. In the case above IIRC the accessible name
would be the text, but the author can override it with aria-label or so.

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

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

I think it's a bad idea to work around accessibility failures in OS X (and
others) when designing new HTML features. It would be better for OS X (and
others) to fix their accessibility failures so that all disclosure triangles
are usable by people with motor disabilities, not just Web apps that use
<dialog>.

> having the
> summary element represent the click area by default = built in 
> usability/accessibility.

Unfortunately it makes it *not* usable when it includes interactive content.

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

Received on Wednesday, 2 April 2014 09:00:32 UTC