- From: <bugzilla@jessica.w3.org>
- Date: Wed, 02 Apr 2014 17:30:10 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25140 --- Comment #9 from Simon Pieters <simonp@opera.com> --- (In reply to steve faulkner from comment #8) > 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 As I said, you can use aria-label to override it if it gets nonsensical. That's what aria-label is for. However the example is hypothetical, I'm not convinced it's an issue in practice. Looking at the examples in comment 2 they would all be fine. > how are we working around OSX issues? why replicate a poor UI? My understanding from your earlier comment was that one motivation for the default action was to get usability for people with motor disabilities for <details> also on platforms that normally have poor usability for the disclosure triangles. That seems like a workaround to me. I don't agree that it's poor UI. I can buy that the click area is small, but one possible solution to that is to make it bigger... Usually HTML features that are also available natively in the platform follow platform conventions (e.g. focus behavior). > 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, Right. But being a minority use case doesn't mean it shouldn't be addressed. > 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 Can you elaborate on this? I don't understand what you're proposing here. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 2 April 2014 17:30:11 UTC