Implementation Details request on Issue 204 Decision (was RE: FORMAL OBJECTION (was RE: Working Group Decision on ISSUE-204 aria-hidden))

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