- From: Janina Sajka <janina@rednote.net>
- Date: Mon, 1 Oct 2012 13:28:47 -0400
- To: Richard Schwerdtfeger <schwer@us.ibm.com>
- Cc: public-html-a11y@w3.org, w3c-wai-pf@w3.org, faulkner.steve@gmail.com, "Edward O'Connor" <eoconnor@apple.com>, public-html@w3.org
Thanks, Rich. It'll be on the agenda for Thursday's TF call. PS: I'm cc'ing Ted and the HTMl-WG as a heads up that we're not quite done with Sec. 7.1. Janina Richard Schwerdtfeger writes: > > I would like to discuss these points on this weeks HTML accessibility task > force call. There is a concern that some of the text will confuse authors. > > 1. We read this text and we don't believe this text was agreed upon by > anyone and we have doubts this is enforceable: > > "The hidden attribute must not be used to hide content that could > legitimately be shown in another presentation. For example, it is incorrect > to use hidden to hide panels in a tabbed dialog, because the tabbed > interface is merely a kind of overflow presentation — one could equally > well just show all the form controls in one big page with a scrollbar. It > is similarly incorrect to use this attribute to hide content just from one > presentation — if something is marked hidden, it is hidden from all > presentations, including, for instance, screen readers." > > From an accessibility perspective it does not really hurt us but if it were > actually enforceable it would frustrate authors who want to use hidden over > CSS display:none. This will just cause authors to not use this feature of > HTML5. There are lots of other examples of this, menus hidden at the bottom > of the page, etc. Futhermore, how are most authors going to know what the > user agent is going to hide to a screen reader? > > 2. This text is incredibly vague and because it is so I don't have an issue > with it and because ARIA 1.0 does allow stripping semantics to produce the > text strings I don't have an issue. Developers who actually read this will > just shake their head and move on: > > "While hiding the descriptions implies that they are not useful alone, they > could be written in such a way that they are useful in the specific context > of being referenced from the images that they describe." > > 3. This API features is only available in IA2 and ATK/ATSPI today and even > then the only browser that supports these two APIs does not expose hidden > content: > > "Accessibility APIs are encouraged to provide a way to expose structured > content while marking it as hidden in the default view. Such content should > not be perceivable to users in the normal document flow in any modality, > whether using Assistive Technology (AT) or mainstream User Agents." > > The ARIA working group should try to address whatever the editors would > like to see here in the ARIA 1.1 time frame, providing Apple and Microsoft > are able enhance their accessibility API in that time frame. There will > also be issues about exposing hidden content that Mozilla will also need to > address. > > 4. This text refers to content being active but what is not clear is > whether "active" hidden text would appear in the tab order. We don't > believe that is the case but it needs to be stated somewhere. Also, the > text for active refers to form controls (which are normally found in the > tab order). Is the intent to only address form controls and should that > somehow should be restated here? For example, what happens when you have > <div tabindex="0" hidden>. Does the div appear in the tab order? > > "Elements in a section hidden by the hidden attribute are still active, > e.g. scripts and form controls in such sections still execute and submit > respectively. Only their presentation to the user changes." > > Janina, please add this to the agenda. > > Thanks, > Rich > > > Rich Schwerdtfeger -- Janina Sajka, Phone: +1.443.300.2200 sip:janina@asterisk.rednote.net Email: janina@rednote.net The Linux Foundation Chair, Open Accessibility: http://a11y.org The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI) Chair, Protocols & Formats http://www.w3.org/wai/pf Indie UI http://www.w3.org/WAI/IndieUI/
Received on Monday, 1 October 2012 17:29:17 UTC