- From: John Foliot <john@foliot.ca>
- Date: Mon, 20 Aug 2012 23:34:02 -0700
- To: "'Maciej Stachowiak'" <mjs@apple.com>
- Cc: <public-html@w3.org>, "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>
Maciej Stachowiak wrote: > > Let me see if this is clear: > > In Safari, aria-describedby (and aria properties in general) are only > exposed via output-side assistive technologies. This includes screen > readers and braille output, and perhaps also other things. This is true > today, and likely would remain true if we exposed full semantics, not > just flattened output. Even though we have no immediate plans to change > it, it's possible that this could change. [snip] > VoiceOver displays everything it speaks on the screen by default. If a > sighted mouth-stick user enabled VoiceOver, the screen would display > long descriptions. That's something that is true today. That is what > the website statement refers to. If a blind user has VoiceOver enabled, > a sighted user can stand near them and see everything the VoiceOver > user hears. > > At this point, I feel like I'm having to repeat the same points > multiple times, so if you still have questions about how Safari and > VoiceOver work, perhaps we could take them offline (e.g. phone). Hi Maciej, Thanks for putting up with my questions. I believe you are very clear here, but that clarity raises a number of new questions for me. And while I certainly welcome a call or in-person chat at any time convenient to you, I think there is also value in continuing this exploration in a more public forum, and so I would like to continue here as well. In your response above, you state both that aria-describedby and other aria properties and values are only exposed to output-side Assistive Technologies, but then go on to state that when VoiceOver is activated, the screen will display whatever VoiceOver speaks aloud by default. If I am to understand this correctly then, toggling VoiceOver "on" (enabled) will invoke a visual change to the page(s) viewed (at least in Safari) if/when required; ie: an aria-label value (<div aria-label="wonder widget"> for example) will be displayed on screen when using VoiceOver, even if it is not normally visible to users NOT using VoiceOver. > If a blind user has VoiceOver enabled, > a sighted user can stand near them and see everything the VoiceOver > user hears. If this is indeed the case, then are we also assume that using the new technique delivered via the current Issue 204 decision, that Safari+VoiceOver will also toggle the @hidden state from "true" to "false" (setting aside for the immediate moment that this is not how the Boolean states of @hidden are expressed in HTML5)? I ask this, as how else would the semantic structures of the aria-describedby but @hidden content be visually rendered so that "VoiceOver displays everything it speaks on the screen by default."? > This is true > today, and likely would remain true if we exposed full semantics, not > just flattened output. Assuming that this is indeed how things would work for Safari+VoiceOver (where Apple has the luxury of the tighter binding of the two "native" applications on your devices), has there been any discussion or thought on how this might also work with other tools, including other browsers and other, 3rd Party screen reading tools such as JAWs or NVDA (or Orca, Hal/SuperNova, ZoomText, etc.)? Currently, I am unaware of any 3rd party AT tool that 'advertises' its presence to web browsers. In fact, I know that at least regarding JAWs, Freedom Scientific is fairly adamant that their tool not be "discoverable" in such a fashion, citing user privacy concerns: at issue is that some users of these tools may not want to announce publicly that they are visually impaired (or even simply that they are using a screen reader). As such, this has been seen as a problem for many years by some web developers, who have wanted to have this ability, so that they could then 'craft' an alternative experience for the non-sighted user. I realize that this is likely outside of the scope of what you can say (as it involves reactions and comments from outside of Apple), but do you know if Jonas or Matt or any of the other supporters of the current decision have any feedback here? Are you or anyone else aware of any discussions with these 3rd party vendors to see how they will work in cooperation with browsers to afford this toggling capacity? (I ask this in light of the "Exit CR" discussions, as without at least one other full public implementation of this technique, I suspect that the Issue 204 decision would become a Feature at Risk moving forward). Returning to how you envision this might work in Safari+VoiceOver, I am also curious about a few other things. For one, how *will* the toggling/over-riding of @hidden be handled? Will VoiceOver invoke a re-writing of the DOM tree to remove any and all instances of @hidden, or do you have something else in mind? Since the previously hidden but now exposed semantically rich will be rendered on screen, will this content also support CSS style properties? (I would think they would, but am unsure). What will happen to the page layout when a large block of new, semantically rich content is rendered on screen? How/where will it render? I would presume that the content would render in the logical relative position afforded by the DOM order (but I also suppose that the block, which when visible and supporting CSS, could be placed anywhere using CSS - *IF* CSS is supported), but a reading of the currently accepted Change proposal seems to be silent on specifics of how this will work. To aid in the testing and explanation of all of these questions, I have taken the liberty of posting a test-suite page at http://john.foliot.ca/html5/w3c/longer_descriptions/ In the first example of aria-describedby + @hidden and inline longer textual descriptions (http://john.foliot.ca/html5/w3c/longer_descriptions/index.html#option1), will invoking VoiceOver push the sentence preceding the info-graphic 'down' and then render the semantic content below the image (something like how <details> is envisioned to work?) Or do you envision something different? Maciej, I thank you in advance for any further feedback you can provide. I also welcome others to answer the current questions I pose, as I appreciate that some of the questions are certainly outside of the scope of Apple's product offerings. Cheers! JF
Received on Tuesday, 21 August 2012 06:34:38 UTC