Re: Response to: ChangeProposals/DeprecateLongdesc

Hi John,

This is an interesting read. Considering all this background, I'm most
undecided about the need for @longdesc for images - I'd almost say
that @longdesc and @aria-describedby fulfill slightly different user
needs (one is push content, the other pull) and it can be useful to
have both. But let me give you some feedback on your document,
hopefully in a means that will help you improve it.


1. Discoverability

Isn't the problem of discoverability the same for either solution, in
fact for any solution? If so, I don't think it's an argument for or
against any solution - it's just reality that we have to deal with.

Note that your proposal strongly supports the move of @longdesc to the
context menu, which in turn makes the availability of a @longdesc link
much harder to discover for screen reader users because they have to
open the context menu to find out, while @aria-describedby will just
push the description at them. So, if anything, the discoverability
argument is not going in your favor.


2. User Choice

The problem of aria-describedby automatically starting to read out the
description is not as a big a problem as you make it out to be. Every
screen reader has a key that stops the screen reader from continuing
to read what it is currently reading - a fundamental feature which was
also the first one I learnt because poorly marked up pages get
annoying very quickly. So, you can always stop the reading or a
aria-describedby description when you've had enough. It's a user
choice whether they prefer push information or pull information - I
personally would prefer push with the ability to turn it off,
actually, than having to be offered the availability of the
information and make an active choice to listen to it every time.


3. "Same experience" argument

In the "User Choice" section you also have an argument about "same
experience". That to me is just an artificial discussion about the
choice of words. I am sure Jonas actually meant to say "equivalent
experience" when he said "same experience". I think this is a nit-pick
that is making the arguments weaker.

As for the question about which provides better support for an
"equivalent experience" - I don't think either works better: they both
provide people with special needs additional assistance by providing
extra text.


4. Usefulness for non-accessibility uses

One argument that can be made more explicitly is that @longdesc can be
used to provide hidden extra long descriptive text to everyone,
including sighted users. With @aria-describedby and assuming that the
long descriptive text is not wished to be exposed on the page, it can
only be provided as hidden and thus won't be available to users that
don't use a screen reader, while one provided with @longdesc can be
provided in a context menu as a link.


5. Potential for Harm

The explanations here show that different accessibility APIs deal with
@aria-describedby in different manners. It seems that UIA implemented
it as a reference, such that when the user gets there, they will get
the full markup richness in both hidden and showing states. To me that
is an argument that it is possible to implement @aria-describedby in
the manner in which Jonas proposes to. That the other accessibility
APIs have implemented it differently and therefore cannot deal with
some situations, such as hidden text or markup, is to me a sign that
the specification is not strict enough to ascertain compatibility and
that it has to be made stricter and bugs filed on some
implementations.


6. Changes to @hidden

You ask "How does one point to something that does not exist?". It's
actually really easy: it's in the DOM, so it's easy to point to and to
use by the browser and all its APIs, including the a11y API.

Also, maybe we should propose a change to the HTML spec:
"The hidden attribute is a boolean attribute. When specified on an
element, it indicates that the element is not yet, or is no longer,
relevant. User agents should not render elements that have the hidden
attribute specified."

should become

"The hidden attribute is a boolean attribute. When specified on an
element, it indicates that the element is not yet, or is no longer,
*visually* relevant. User agents should not render elements that have
the hidden attribute specified."

Also, the further text would need a change, too - in particular this
cannot stay as is:
"if something is marked hidden, it is hidden from all presentations,
including, for instance, screen readers."
Something would need to be added about hiding it from screen readers
in their normal page progression, which is indeed necessary, but not
hiding it from @aria-describedby. Maybe @aria-describedby would create
a temporally restricted unhiding and focus for tabbing, similar to how
modal dialogs work.


7. A though on the Context Menu

I wonder if it would be an idea to extract all links provided in the
@aria-describedby referenced html fragment and add them to the context
menu of the image. That would allow to retain the @longdesc
functionality and at the same time allow on-page and off-page long
descriptions. It would also be more flexible because there could
likely be several links added to the context menu. It would indeed be
a simple means to generally extend a context menu and would also work
for video, audio etc. Hmmm.... As you say: indeed it all burns down to
what the UAs do with the markup.


OK, enough thoughts for the day. I hope this helps.

Cheers,
Silvia.



On Tue, Aug 23, 2011 at 12:28 AM, John Foliot <jfoliot@stanford.edu> wrote:
> In preparation for the text sub-team's teleconference of Aug. 22, please
> find my draft response here:
>
> Response to: ChangeProposals/DeprecateLongdesc -
> http://www.w3.org/wiki/User:Jfoliot/longdescresponse
>
> Cheers!
>
> JF
>
>
>

Received on Monday, 22 August 2011 23:07:38 UTC