why are we pursuing this idea? (was: Implementation Details request on Issue 204 Decision)

Hi all,

I have kept out of the discussion, but I am struggling to understand all of
this.

It seems to me we have moved from the notion of being able to activate a
visually hidden link with AT, via ascribing its action to an associated
image:

This is essentially what longdesc does as implemented in Firefox today,
same as what the new Firefox implementation does via aria-describedby[1]
Note that firefox uses the same accessible action for both (showLongdesc()).

My understanding is/was that the ability to reference a hidden link was for
the (in my mind) edge case where the design  will not allow a 'visual
incumberence' i.e a visible link.

In the vast majority of circumstances we should be advocating the use of
visible content and visible interactions to access content for all users,
not devising elaborate methods to display hidden content to AT only users.

I am not an AT or browser developer, but I am someone who provides ( and
has done so for going on 12 years) advice to many organisations large and
small on how to provide accessible content. I cannot think of one use case
for which I would advise the use of this proposed feature. At the same time
there is not one use case I would advise or have advised for the use of
longdesc as currently implemented (or not).

I can see a use for the aria-describedby implementation in Firefox, but I
would not personally be advocating its use unless the associated link was
made visible at some point (for example when the image is focused or
hovered). And in most instances would be advocating the use of a default
visible link .The value of the describedby and longdesc implementations
being that they can provide an explicit linked URL with an action to an
image. The advantage of the describedby method over longdesc is that by
default it is exposed as part of the default UI (as a regular link), but
can be hidden if the use case 'no visual incumberence' is required.


given that we have entrenched positions on both sides I would like to
propose a comprimise:

we accept the use of aria-describedby as implemented in firefox and see if
we can converge on that.

we allow longdesc, but improve it so that it can either take a URL (as it
does currently) and it can also take an ID reference if as implemented in
firefox that id reference points to a link then it does the same as the
describedby and uses the href content of the link as the actionable URL. In
other words its a special case native HTML describedby.


This means we will have a longdesc (that still works for current AT), that
can use a visible link or point to in page content (non link ID) and so
does not suffer from hidden content syndrome, but does provide the ability
to explicitly associate a rich text description of the image. and IF we
must hide the link it can be done.


the implementation in browsers as shown by firefox for both describedby and
longdesc is simple (relatively) and I believe orders of magnitude simpler
than what is being discussed. I also think that some AT will simply not
implement the rich hidden content model as described, The NVDA developers
have not implemented longdesc due to it having no visible UI (for example).

We move away from the territory of large swathes of content only visible to
AT.

regards
SteveF

[1]
http://www.paciellogroup.com/blog/2012/05/firefox-14-image-long-description-via-link-using-aria-describedby/

On 21 August 2012 07:34, John Foliot <john@foliot.ca> wrote:

> 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
>
>
>


-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html