RE: ISSUE-30 longdesc - Chairs Solicit Alternate Proposals or Counter-Proposals

Jonas Sicking wrote:
> >
> > 1.)     Backward Compatibility
> >
> >        We believe it is important to support users with older
> >        technologies in this feature. The CP we backed does this, and
> we
> >        are keenly concerned that the approach adopted for HTML 5 do
> >        so as well.
> >
> >        http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc
> >        http://lists.w3.org/Archives/Public/public-
> html/2011May/0170.html
>
> I'm not sure I understand what you mean by this requirement. Note that
> HTML5 already has the same requirements on user agents as HTML4 with
> regards to longdesc. I do not propose to change that, nor have I heard
> anyone proposing to change that ever as long as HTML5 has been
> discussed. So any behavior that users see today will remain once user
> agents implement HTML5.

Removing @longdesc while a "complete" functional equivalent does not exist
breaks backward compatibility. Most significantly, it expressly disallows
older content to be considered conformant HTML5, forcing existing content
to either remain non-conformant or abandon existent functionality wile a
replacement does not exists.

Those of us who are concerned about this issue acknowledge that *some*
user-agents (browsers) have not yet chosen to support this decade+ old
attribute, but some have, and Adaptive Technology that works in unison
with browsers to complete the user-agent pact with non-sighted users *do*
support @longdesc. For this reason supporting backward compatibility is
deemed important if not critical.


>
> > 2.)     Display content only upon user request
> >
> >        A key behavioral requirement for this feature is that the
> >        content of the long text description is displayed/voiced ONLY
> >        when the user requests it. In other words users need to know
> >        that a longer textual description is available, and they need
> to
> >        be able to easily request that content be presented to them--
> or
> >        not. In no instance, however, should such content be
> >        automatically displayed, as alt text is automatically
> displayed.
> >        This behavioral distinction is one key distinction between the
> >        required short and long text description mechanisms as
> described
> >        by WAI at:
> >
> >        http://www.w3.org/2009/06/Text-Alternatives-in-HTML5.html
>
> This requirement seems very poorly phrased. Surely you don't want long
> descriptions to always be hidden from the user unless explicitly
> requested? Consider for example the page http://apod.nasa.gov/apod/ .
> For people not using AT, the description is always displayed below the
> image. Similarly, today, users which use AT will have this description
> read to them as part of the normal page flow.

Great. This is a well annotated photo, but it is not a "description".
While NASA does a good job telling you the background of the photo
("Pictured above, the large Shuttle Crawler Transporter rolls the powerful
orbiter along the five-kilometer long road at less than two kilometers per
hour. Over 15,000 spectators, some visible on the right, were on hand for
the historic roll out."), what is missing (but that you can see) is this:

	"The photograph is taken at night. The white space shuttle
attached to the yellow launcher-rocker is illuminated by powerful
floodlights, and stands majestically against a pitch-black sky; no stars
can be seen. To the right of the shuttle, you can make out the vague
shapes of people watching the shuttle progress to its launch spot, the
lights of support vehicles and police cars serving to illustrate the sheer
size and massiveness of the shuttle itself."

That is a long description for that photo.

>
> Are you saying that this page should be authored differently such that
> AT users in this case should see a mostly blank page with just an
> image for which they could request a description if they wanted it? If
> so, how does longdesc solve this requirement? The existence of
> longdesc clearly didn't prevent the above site from providing a
> description in the page in a way that it's automatically read to
> AT-users.

This is a bad example. Consider instead the cartoon use-case (of which we
have repeatedly used CSSquirrel as an example). The cartoonist has, as
part of drawing the cartoon, included "speech bubbles" between the
characters in the strip, and every sighted user can read the dialog in the
strip. In this instance, neither <details> nor plain, on-page text is
going to find acceptance by the author.

[Can you imagine if I hand wrote this sentence and then was told that to
insure it was accessible that I repeat the sentence in machine readable
text?]

Can you imagine if I hand wrote this sentence and then was told that to
insure it was accessible that I repeat the sentence in machine readable
text?


>
> What I can understand though is wanting to be *able* to author pages
> such that a description is only available if explicitly requested. My
> proposal will certainly support that. Here are some examples:
>
> Providing a description in an external page. AT-users will be notified
> that the description exists. Non-AT users could be notified using for
> example a context menu item:
> <img src="..." aria-describedby="desc">
> <a hidden href="other.html" id=desc>

How does older technologies process this?

The @hidden attribute is currently new for HTML5, and currently lacks
support in 3 of the 5 browsers, thus failing on the backward compatibility
requirement. Further as of March of this year content within elements that
have a @hidden attribute are not displayed or _navigable_
(http://www.html5accessibility.com/). Will your Change Proposal mandate
that this change?


>
> Providing a description in an external page while showing the link on
> the page for non-AT users:
> <img src="..." aria-describedby="desc">
> <a aria-hidden href="other.html" id=desc>

This will not be workable. The ARIA Candidate Recommendation states:
	"Indicates that the element and all of its descendants are not
visible or _perceivable_ to *any* user as implemented by the author."
(emphasis mine)

http://www.w3.org/TR/wai-aria/states_and_properties#aria-hidden


>
> Providing a description in the normal page flow while allowing
> AT-users to automatically jump to it:
> <img src="..." aria-describedby="desc">
> <p id=desc>long description here</p>

This fails on the requirement "description is only available if explicitly
requested". Rightly or wrongly (and what ships is generally "right" we're
told) this will force-read the long description on screen-readers without
a pause.


>
> Providing a description in the same document (to make it easy to keep
> it up-to-date) while still displaying it only to AT users as to
> satisfy esthetic design requirements for seeing users:
> <img src="..." aria-describedby="desc">
> <p hidden id=desc>long description here</p>

See comments above re: @hidden


>
> Providing a description in the normal page flow for non-AT users,
> while letting AT users only see it if explicitly requested:
> <img src="..." aria-describedby="desc">
> <p aria-hidden id=desc>long description here</p>

See comments above re: @aria-hidden

Further, the ARIA spec also states:

"Authors MAY, with caution, use aria-hidden to hide visibly rendered
content from assistive technologies only if the act of hiding this content
is intended to improve the experience for users of assistive technologies
by removing redundant or extraneous content. Authors using aria-hidden to
hide visible content from screen readers MUST ensure that identical or
equivalent meaning and functionality is exposed to assistive technologies.

Note: Authors are advised to use extreme caution and consider a wide range
of disabilities when hiding visibly rendered content from assistive
technologies. For example, a sighted, dexterity-impaired individual may
use voice-controlled assistive technologies to access a visual interface.
If an author hides visible link text "Go to checkout" and exposes similar,
yet non-identical link text "Check out now" to the accessibility API, the
user may be unable to access the interface they perceive using voice
control. Similar problems may also arise for screen reader users. For
example, a sighted telephone support technician may attempt to have the
blind screen reader user click the "Go to checkout" link, which they may
be unable to find using a type-ahead item search ("Go to…")."




>
>
> > 3.)     Provide a reliable and effective user experience
> >
> >        Inasmuch as ARIA is new technology not yet fully or
> consistently
> >        implemented by browsers or AT, how will you propose that your
> >        ARIA based long text description can serve users needs
> >        effectively and consistently, regardless of what particular
> >        browser or particular AT a user may employ? In asking this
> >        question we note that the CP we have endorsed DOES provide
> >        effective and consistent support for users regardless of
> browser
> >        and AT, and we believe they deserve that kind of support.
>
> I'm not really sure what this requirement is asking for. Of course
> HTML5 or ARIA isn't fully implemented yet. If we're ever hoping to
> improve the web we have to add features to it, and there will always
> be a time between those features are added to specifications and they
> are implemented. This surely was the situation when longdesc was added
> too.

And in fact, it remains the situation today - we are still waiting for GUI
user-agents to provide better support for @longdesc, while noting that
other tools have pulled ahead of the browsers in this support (where other
tools = mainstream screen readers).

Many of your ideas warrant further discussion, and they may some-day
provide a functional replacement for @longdesc. However, that day is not
yet upon us, and the core issue many of us have *today* is that by
abandoning @longdesc while we try and figure out other replacements has a
negative impact on the progress made with @longdesc. It makes current
conformant HTML non-conformant, it ignores evidence on the ground w.r.t.
authoring guides, legal requirements, 3rd party authoring tools, and it
has real and tangible impact on affected end users.

Maybe in HTML6, or HTML7 it will be time to retire @longdesc as an
authoring recommendation in favor of better solutions. But until we have a
reasonable status and stable of alternative methods of ensuring a good and
respectful user-experience for all users, we argue leaving @longdesc in
HTML5 is the best solution today. No-one (well, certainly not I) thinks
that @longdesc is perfect, however, just like democracy it is better than
all the other solutions on the table today. The current situation of
making it obsolete serves no technical purpose, it is simply the misguided
social engineering attempt of some, who failed to understand the
significance and nuances of the decision they seek to impose.


>
> Given that HTML5 has the same user agent requirements with regards to
> longdesc as HTML4 does, I don't see that my proposal should give any
> problems supporting down-level browsers. And even if HTML5 removed
> those user agent requirements authors could always add both longdesc
> and aria-describedby attributes.

The problem is not just the down-level browsers, it is the other tools
that work in concert with those older browsers. The continued question in
my circles is, why can't the browsers "up their game" in supporting
@longdesc, an attribute we've had since 1999? Rather than keep the HTML5
spec down, let's challenge the browsers to rise to the ideal. Is it really
that hard to support @longdesc for all users? Is this really the hardest
technical burden the browser vendors face today?

JF

Received on Tuesday, 21 June 2011 01:36:46 UTC