- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 14 Aug 2012 13:03:34 -0700
- To: Janina Sajka <janina@rednote.net>
- Cc: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>, John Foliot <john@foliot.ca>, Sam Ruby <rubys@intertwingly.net>, public-html@w3.org, HTML Accessibility Task Force <public-html-a11y@w3.org>
To be clear, here is what I would expect us to do, if we were to implement the "encouraged" rich semantics functionality in WebKit. Consider the scenario where aria-describeby on an element points to hidden content, which contains a link. This is John's original example. Here is what I would expect to happen for different classes of users: (1) Sighted user, using either keyboard or pointing device to manipulate the content, and with no screen reader or assistive technology running: - The aria-describedby description would not be exposed to such a user at all. They would neither see it nor be able to tab into it. (2) Same as #1, but using a custom input accommodation, such as a mouth-stick or sticky keys. - Same experience as #1 - the description is not exposed at all. (3) User using the VoiceOver interface exclusively, and not relying on the screen. - They would be able to navigate into the hidden content, but using VoiceOver keys, not tab. (4) Partially sighted user, using VoiceOver in combination with the screen. - They would be able to navigate into the hidden content, but using VoiceOver keys, not tab. - The VoiceOver interface naturally visually displays all spoken text. And it generally highlights the described item when speaking a description, even if that description is indirect or structured. For (3) and (4), we might also find that a visual overlay of the full structured description is a fruitful approach. The VoiceOver experience tries to display everything on the screen, both for benefit of partially sighted users, and to enable collaboration between sighted and blind or visually impaired users. This might be a case where we would go beyond the default display of any content. It may be that there are UAs or ATs that would find this hard to implement. That is a fair point, but exposing semantics is "encouraged" not "required". It may also be that there are some UAs that would inadvertantly allow tab focus into invisible content, perhaps due to hard implementation constraints. I do not see this as inevitable. I do not believe it would be the case with WebKit. It may also be that there are problems with the approach above. But it does not seem to me that tab-focus into invisible content is one of them. If there are other problems, it would be great to know! Regards, Maciej On Aug 14, 2012, at 12:32 PM, Janina Sajka <janina@rednote.net> wrote: > There's also a large set of users/use.cases where the a11y accomodation > is input side, not output side. A simple example is the mouth-stick user > who requires sticky keys, and not much else. They will > TAB/otherwise.navigate into a morase of content that is not displayed on > screen. > > > Bottom line that seems to have been missed is that there are users who > use the same display as non a11y, but do not use--cannot use pointing > devices. These are some of the users that will wander into the > structural focus points for which no display exists. > > Janina > > Benjamin Hawkes-Lewis writes: >> On Tue, Aug 14, 2012 at 5:57 PM, Maciej Stachowiak <mjs@apple.com> wrote: >>> I believe my remark below is equally applicable to your comment. To my understanding as an implementor, hidden content can be exposed to assistive technologies (including screen readers such as VoiceOver) without exposing it to the TAB cycle for keyboard users. Thus, non-screen-reader users making use of the keyboard will not experience a problem, as they will not tab into invisible content. My understanding of the specific concern raised by John, both in his survey comment and in his formal objection below, is that exposing content with full semantics to assistive technologies will inevitably put it in the tab cycle, thus leading to the harm both of you are worried about, namely sighted keyboard users tabbing into invisible content. The point of information I wanted to provide is that it does not necessarily have this effect, for either screen reader users, or users viewing the screen and navigating with the keyboard. >> >> I think the big disconnect in this conversation may be that assistive >> technology often uses accessibility APIs to provide a user experience >> that extends and depends upon, rather than simply replacing, the base >> user experience provided by the browser. The concern here, I think, is >> that if the long description remains visually hidden there is no user >> experience to extend. >> >> Consider a person with partial sight using VoiceOver. The object under >> the VoiceOver cursor is indicated visually (as well as being spoken or >> brailled) using a visual indicator (a black rectangle). If the >> VoiceOver cursor descended into a subtree in the accessibility >> hierarchy that has no equivalent in the visual layout, what would the >> black rectangle be drawn around? >> >> A naive implementation would be for VoiceOver to draw it around the >> object described. This has the disadvantage that the user cannot >> visually distinguish between focus on different parts of the complex >> long description. For example, if the long description contained >> multiple controls, you would not be able to tell (visually), which >> control would be activated. This would be a major departure from the >> general user experience of using mixed aural/braille and video output. >> >> A more sophisticated implementation would be for VoiceOver to draw an >> overlay, perhaps similar to the existing Item Chooser, that exposes >> the structure, content, and functionality of the long description >> visually. I'm guessing this is what Maciej is envisaging. >> >> Different combinations of user agents and assistive technology could >> divide responsibility for maintaining visible focus in dfferent. For >> example, maybe Internet Explorer might provide an accessibility API >> method on the described object to navigate to a hidden long >> description. When called by an AT such as JAWS, Internet Explorer >> would render an overlay exposing the structure, content, and >> functionality of the long description. JAWS would then draw focus >> indicators into the overlay rendered by Internet Explorer. >> >> The WG needs to recognise that a lot of different software would need >> to be updated for this to work and that many critical vendors aren't >> really represented here. For example, NVDA tends to adopt a minimal >> approach to extending the base experience. Rendering an overlay itself >> would be quite a departure. So I think we're looking at a major >> implementation commitment to make it work. >> >> (I think there are other big difficulties here, like the fact that >> @aria-describedby isn't suited for pointing to long descriptions at >> all since it is used to populate a plain text "accessibility >> description" field in accessibility APIs.) >> >> -- >> Benjamin Hawkes-Lewis > > -- > > 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 Tuesday, 14 August 2012 20:03:30 UTC