[Bug 25140] restrict summary element content?

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

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

there in lies the issue, the acc name for the above example would be:

" major pain also show minor pain (max number of minor pains)"

nonsensical

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

how are we working around OSX issues? why replicate a poor UI?

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

right and that's why i have suggested restricting, as from an adhoc review the
majority of uses don't require the addition of other controls, But as a
compromise being able to define a label area for summary that acts like a label
on a labelled control would cover both cases. providing both
usability/accessibility benfifits and the flexibility of allowing additional
controls

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

Received on Wednesday, 2 April 2014 13:08:59 UTC