Re: Review of Section 7.1 by ARIA working group in PF

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:19 UTC