RE: TF response to your comments on HTML5 Image Description Extension (longdesc)

James Craig wrote:
>
> >> WCAG Principle 4: Robust - Content must be robust enough that it can
> >> be interpreted reliably by a wide variety of user agents, including
> >> assistive technologies.
> >
> > As I understand it, the longdesc attribute *CAN* be reliably
> > interpreted by a wide variety of user agents
>
> The longdesc attribute is not content. The longdesc attribute is just
> one of many ways to associate two pieces of content. The more ways you
> associate or provide that content in a variety of formats, the more
> robust it will be.

Then James, using that line of reasoning:

a) the longdesc attribute can link to a fully conformant, fully marked up,
semantic *and thus robust* document that provides a longer description of a
complex image.

b) "The more ways you associate or provide that content..." - which means
that support for conformant @longdesc is *one more way* of supporting the
provision of long descriptions, in addition to the number of ways you have
advocated to date.

This specification in no way suggests that it is the only way, nor even the
"preferred" way, of providing a longer text description. It *does* seek to
keep an established, decade-plus attribute conformant in validators when
used in an HTML5 document, and makes access to this information that much
more robust, because we're providing yet "one more way".


> >
> > I am not clearly understanding your comment here. Are you suggesting
> > that AUTHORS shouldn't provide "robust content" (my interpretation of
> > that phrase = detailed longer descriptions when appropriate)?
>
> I am suggesting that any and all W3C specs should encourage authors to
> provide robust content. Would you still oppose the proposed text if we
> removed the word "longdesc" and replaced it with something else?

Once again, you are mixing your own definition of robustness. At the end of
the day, yes, we should be encouraging content authors to provide "robust"
content to all users, which means that complex images SHOULD also contain
textual equivalents for those users who need or prefer that content. What
you seem to be opposing is *how* that textual content be associated to the
image, yet earlier you suggested that the more ways the better.

We have content publishers (Pearson) and instructional providers (DIAGRAM
Project) who are both teaching content creators about the need for, and the
means of, both writing those longer descriptions (the harder task BTW), and
on how to associate that content to the images. These parties also recognize
that "the more ways the better", but that sometimes they cannot impose any
visual encumbrance on the on-screen content. In that case, one way to
provide the content is to use @longdesc - it has good if not ideal support
already, and if the browser vendors seized the opportunity, they could make
that support better.


>
> Modified:
> >>>> Authors MUST NOT rely on *any* specific feature as the sole means
> >>>> to provide access to information which is essential for the user.

Right, which by extension could also mean then that I cannot *solely* rely
on MathML (today) - a comment educators have already made to this working
group. We cannot rely *solely* on accessible SVG today - as user-agent
support is extremely weak. In fact, we cannot rely *solely* on any of the
alternative techniques you have suggested, for a variety of reasons,
including the fact that design considerations are a factor that content
creators cannot dismiss with a wave of their hand.

This comes back to your point of *choice*, and removing a choice, rather
than accepting its existence in the wild (and earlier specifications) and
improving on its user-agent support, is a step backwards.


>
> Longdesc is known to not be supported for any users in Chrome and
> Safari, and only supported for assistive technology users in Internet
> Explorer. (No need to link to the polyfills again. I've seen them.)

Actually, Chrome + ChromeVox provide support for longdesc, and Firefox +
NVDA, JAWs and now Orca also provide support. The fact that native support
for sighted users remains woefully poor is not discounted, but like
accessible MathML and accessible SVG, we (*I*) remain hopeful that support
will increase.


> Regardless if we agree on longdesc being a *good* feature, it is just
> one not-particularly-well-supported way to associate content.
> Therefore, it's wise to recommend that "essential" content MUST or
> SHOULD be associated in a robust way in addition to longdesc.

This seems to be the crux of your argument. The thing is, you seem to be
very quick to discount the fact that for one significantly affected
user-group - those who cannot see the image - support from their "user-agent
stack" is actually pretty robust on both the Windows and Linux platforms.
And while I would love to see a more robust support solution emerge native
to all the browsers, for sighted users who would benefit from @longdesc
linked content, for those sighted users who already need this type of
on-screen support we *do* have multiple browser extensions that address
their need. By using both a browser and an additional piece of software, a
workable (if not ideal) solution exists.

This is similar to literacy aid tools, that both read aloud and visually
highlight text on screen (see: Read/Write Gold), a solution that appears to
be acceptable to both the user groups, and apparently the majority of
browser vendors as well, who have no qualms handing off "accommodation"
support like this to third party "bolt-on" tools. (Yes, I know that this
feature is also native to iOS, but not other platforms. However neither
Apple nor the W3C are in a position to mandate that either, and so for many
users, they *do* bolt on third-party software, apparently with little ill
effect.)

Yet somehow, you wish to hold @longdesc linked content to a higher standard,
arguing an all-or-none position. I will argue that it is an unrealistic
position to be taking, but it is also apparent you disagree.


> >
> > An extremely simplistic answer to a complex problem statement -
> > personally it leads me to question if you even fully understand the
> problem statement.
>
> It's a simplistic (but nonetheless true) answer because we've hashed
> and rehashed the detailed answers for over 7 years.

And even though you have repeatedly been given detailed answers as to why
such a simplistic solution is unrealistic, you continue to advance it - deaf
to the feedback and responses you've been given over 7 years.


> I don't need or
> wish to spend any more time on it. You've repeatedly questioned our
> intelligence and integrity on this matter, but the objection is founded
> in a fundamental belief that the bolt-on "separate but equal" approach
> is bad for accessibility. Integrity demands we oppose it.

One can only hope then that should @longdesc become a fully conformant part
of the HTML5 specification, that the very same integrity you speak of will
find a way of providing support for the attribute in the user-agents you are
involved with. Given your employer's history of surfacing elegant and
integrated solutions to other tricky UX problems, you stand a real chance of
one again blazing forth with an imaginative solution.

JF

Received on Saturday, 6 September 2014 16:44:48 UTC