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

James Craig wrote:
>
> >
> > YOUR COMMENT #1:
> >> Proposed Additions to "3.0.2 Authors"
> >>
> >> *  Authors MUST NOT rely solely on longdesc as the means to provide
> >> access to information which is essential for the user.
> >
> > DISPOSITION: Not accepted
>
> I understand Joanie's comment on behalf of Igalia to be in line with
> Principle 4 of the Web Content Accessibility Guidelines:
>
> 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
(http://www.d.umn.edu/~lcarlson/research/ld.html#browsers), including many
assistive technologies (http://www.d.umn.edu/~lcarlson/research/ld.html#at).


The fact that the reliability goes down significantly on 2 related operating
systems is unfortunate, but in-and-of-itself not a reason to halt progress
on longdesc. Reliably does not equal universality.


>
> WCAG Guideline 4.1 Compatible: Maximize compatibility with current and
> future user agents, including assistive technologies.

Research has already proven that compatibility with current user-agents is
itself robust, if not universal.


> > Whether a longdesc is essential or nonessential will depend on
> > circumstance. It will vary among users, and will even vary for the
> > same user given different circumstances.
>
> The original comment was about requiring AUTHORS to provide robust
> content for the sake of these USERS. The HTML-A11Y group may have
> overlooked this point. I assume this response was only discussed in a
> conference call; I didn't see it discussed on the email list or I would
> have pointed this out.

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)? In fact, I am unsure what
point you are actually trying to make here. Could you kindly elaborate?


>
> > The point of the longdesc feature is to make it easy for the user to
> > access that information, or to readily skip past it as their needs of
> > the moment may dictate.
>
> There are a number of ways to achieve this, including using a standard
> link.


An extremely simplistic answer to a complex problem statement - personally
it leads me to question if you even fully understand the problem statement.

I urge you to revisit the original Requirements statement
(http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#User_and_Aut
horing_Requirements), and specifically the following:

User Requirements:
	No forced visual encumbrance - The user MUST be able to configure
the longer description mechanism to be visible or not, according to their
needs.

Author Requirements:
	No forced visual encumbrance - By default the long description or
long description indicator MUST not force a visual encumbrance or impact the
visual user experience.


This concern for how adding a longer text description (links) will impact
the final design is not unfounded: close to 25% of screen reader users [1]
and nearly 15% of dedicated web accessibility professionals [2] cite the
impact on look and feel of a web page as a barrier in achieving an
accessible page.

[1 - http://webaim.org/projects/screenreadersurvey5/#reasons]
[2 - http://webaim.org/projects/practitionersurvey/#reasons]

Repeatedly telling us the answer is to just put it in a link completely
ignores this issue. That isn't addressing the issue James, that's dismissing
it as non-valid. Given that we have demonstrably significant numbers to
bolster the validity of the problem, it needs to be addressed.

Does this then place the responsibility on the browsers to actually get this
something close to "right"? You bet. We already have a number of proofs of
concepts (via browser extensions and scripted "plugins") that have led the
way in illustrating how that support *might* look like in the GUI. From my
vantage point however, this will come down to a user-togglable setting in
the browser, similar to the current abilities to over-ride font settings,
link colors, invoke high-contrast, disable images, and numerous other
"display" property modifications that *individual users* can choose to apply
to their personalized "user-agent stack".

The fact that this seems to be such a stretch to the creative thinking of
the UI designers at the various browsers continues to confound and perplex
me.

JF

Received on Wednesday, 3 September 2014 20:20:22 UTC