RE: Response to: ChangeProposals/DeprecateLongdesc

Silvia Pfeiffer wrote
> 
> If we completely disregard UA behavior for arguing this case, then
> discoverability is not an argument either. I am just trying to point
> out where I would see possible issues with your proposal.

I respectfully disagree: we can mandate that the browsers make @longdesc
discoverable without prescribing how that is manifest - convention is
emerging that the trigger is in the contextual menu on the desk-top, but
mobile browsers (for example) would likely deploy another mechanism. Ditto
with the 'signaling' - I suggested something in the chrome, but (for
example) a change in icon with onhover/onfocus of the image might also be
investigated. Discoverability is the key to improving @longdesc for all
users (beyond non-sighted users who are using a screen reader that
supports @longdesc), but how that discoverability is conveyed to the end
(sighted) users is wide open to implementation techniques. (I would
actually love to see/hear of other ideas; it would be very cool if as part
of user-settings the individual user had choice on how the presence was
conveyed to them - think along the lines of custom skinning).


> 
> I agree that the key difference between @aria-describedby and
> @longdesc is what you call "choice": that the first follows the
> push-model, while the second the pull-model ("choice"). I don't regard
> it as a flaw for either of them - they just support different
> interaction models and depending on who you are and your situation,
> you prefer one or the other.

Yes, in principle I would agree with you here. 

With regard to images, the "push" interaction is supplied by @alt, where
authors provide a succinct alternative to the image in question. *Should*
the end-user desire more detailed information about the image (as supplied
by @longdesc) then they can choose to pursue it - "pull" it - (which is
why Chaals called his plug-in "Tell Me More"). In other words, to properly
support complex images, the user requires both push *and* pull features,
which today @alt and @longdesc provide. Images with @alt and
aria-describedby would be images that have 2 push functions, but no pull
function.

(As I write this, I also reflect on the requirement that aria-describedby
content would still need to be made visible to end users to preserve
semantic richness/markup - the 'string-text' issue - and the fact that at
this time, again by design, aria-describedby cannot point to URLs from
which to "pull", it only supports IDREFs)


> It would almost be better if we just had
> one mechanism to provide long descriptions (whichever of the two)

Here we have agreement (at least when it comes to images - more below). 

@longdesc is the 'one of the two' that has legacy support and legacy
content in its favor today, not to mention that it is also more robust in
supporting both URLs and IDREFs. Proponents of @longdesc have long argued
that it's not the attribute that is flawed, but rather the support it has
received in the past from mainstream browsers. If the browsers did
something useful with @longdesc then the attribute itself is extremely
elegant, powerful and useful.


> and
> then a browser preference to set whether you want the browser to push
> the information at you (in the case of @longdesc that would mean:
> downloading the URL and starting to read it out) or pulling the
> information (in the case of @aria-describedby that would mean: waiting
> for a user interaction to read the referenced section(s)).

I think you mean the inverse: @longdesc is the pull (on demand) whilst
aria-describedby is the push (download and start reading). However, once
again I agree that getting some form of browser support that worked for
*all users* would be key. With the exception of Opera (and Camino) none of
the mainstream browsers do anything with @longdesc (except pass on its
presence to the Accessibility APIs) - to date it has been AT that has
carried the water and delivered the functionality to end users.

Specific to Jonas' proposal, he is advocating moving from the pull to the
push model, but not addressing the more critical issue of how that would
play out for end users. (As I am sensing you are now understanding, this
is indeed a browser problem, not a coding problem)


> 
> I agree that there are indeed situations where you want one
> interaction pattern over the other.

I am further suggesting that when it comes to complex images and longer
textual descriptions the norm would likely be an "on-demand" model as
opposed to the "forced-unless-silenced" model, although I freely admit
that is based more on my understanding of the issues as opposed to any
kind of survey of end users.


> Maybe you could have a browser
> setting that automatically read out the content of the referenced
> fragment/document only the first time in one browser session and then
> not again unless the user actively asks for it.

I am unsure how that would actually work (technically), and whether that
would be an ideal suggestion anyway. This seems overly complex (likely
requiring the use of session cookies or some-such): it strikes me as a
problem that really doesn't need to be solved, when instead of push we can
simply use pull. 

In any case, the browsers would still require some method of allowing for
"pull" at some point - "... the user actively asks for it...", and so it
strikes me that you are introducing additional complexity that need not
exist, all so that we can deprecate @longdesc. Do we have any indication
that the browsers would even entertain such functionality? (and please
understand that this is not an "attack" question, but rather just a
logical extension of your blue-skying - which I appreciate for what it is.
This conversation is useful.)


> 
> I guess what I am saying more and more is that no matter which markup
> solution we choose, it eventually comes down to what user interaction
> the browsers implement

BINGO!!

> and that it is possible to implement all the
> user interaction behaviours that are being discussed with either of
> these two approaches, thus making any arguments about the different
> behavious that they currently support insubstantial.

Yes and no. I agree whole-heartedly that in many ways this *is* a browser
issue, but I disagree that either mechanism is appropriate.

Aria-describedby is a more general purpose means of providing an
accessible description to the Accessibility APIs, and ideally that happens
"automatically" - the push model you have described. For example, that
functionality is critical if aria-describedby were to be used like this:

<fieldset>
  <legend>Search this site</legend>
    <p id="instructions">Searching for Rainbows or Unicorns will cause
this website to explode!</p>

    <label for="search">Search</label>
      <input type="text" id="Search" autofocus
aria-describedby="instructions"/>
      <input type="submit" name="search" value="Go">
</fieldset>

(Here, the @autofocus attribute places the virtual cursor at a point
beyond the important search warning, but the aria-describedby allows for
the non-sighted user to still be informed of the crucial search advisory.)

So aria-describedby is used by more than just images; it is more general
purpose than that. I suspect very few non-sighted users would disable the
auto-announce function of aria-describedby, as it would have a negative
impact on examples such as above (and granted, that is conjecture at this
time), so having that feature in the user-settings will break one of the 2
(as advocated by Jonas) uses of aria-describedby at some point. You could
argue that the combination of [aria-describedby + img] is/would be a
special case, but at that point you are setting up a condition that
requires a specialized instance, and we already have a mechanism in HTML
today for that special instance - it's @longdesc.

Silvia, thanks for the feedback to date, and I hope that this helps
clarify things further.

JF

Received on Wednesday, 24 August 2011 15:20:38 UTC