RE: 48-Hour Consensus Call: InstateLongdesc CP Update

David Singer wrote:
> 
> What do non-sighted users do?  What happens in an aural browser?

These are indeed two good questions, but then you also introduce the
additional user-requirements for sighted users. The third (and fourth)
unasked but implied questions are: What do sighted users do? What happens in
a GUI browser?

> 
> Why doesn't the language simply state that "a long description of <this
> image> is <over there>", for those that need the long description?


<img src="images/chart1.png" 
     alt="sales statistics for 2011" 
     a_long_description_of_{this_image}="http://long_description.html">

Is that what you just asked for?

I will additionally point to the final bit of your question: "... for those
that need the long description..." which I think accurately reflects that
not all users (sighted or non-sighted) will always need or want a longer
textual description. So the longer textual description must certainly be
something that they choose to access, as opposed to something thrust upon
them.


> That population might include:
> 
> * people using UAs that cannot render the format of the image (e.g.
> JPEG 2000)
> * people using text-only UAs
> * people with vision impairments
> * people whose eyes are elsewhere (i.e. they are focusing on something
> else)
> * people using aural browsers
> * people who can see the image but can't understand what it is trying
> to convey
> * people who think they do but want every nuance out of the image
> 
> well, you get the message.  I am sure that there are more cases.

All which adequately serve to suggest that the GUI browsers have a role to
play in exposing the longer textual description to the users noted above.  

I honestly don't think changing the name from one thing to another is
solving the actual problem (outside of an attempt to address the "pollution"
problem): at its core we require some programmatic linking mechanism (an
attribute) that points to an additional resource, that resource content not
being restrained by inclusion in the same document as the image itself. We
additionally require a mechanism that allows all users, regardless of
modality, to gain access to that longer description on demand.
(Additionally, that longer textual description content must support HTML
rich marked-up content)


> 
> The important thing is that the availability of a long description
> should be indicated by suitable means (e.g. "want a description or
> fries with that?" for spoken browsers).

Correct, and to address the additional list of users you noted, we need an
indication of some form for sighted users as well. Expecting those users to
seek out an aural browser to perform what they consider visual tasks is to
me a backward and unrealistic expectation.

David, have I misunderstood anything you have stated here? If yes, please
clarify.

*******

Reconciling the 2 Davids (Messrs. Singer and Bolter):

David S. has (to my reading) suggested that a mechanism is required to
advise users of longer textual descriptions. I agree. (I have further
extrapolated that the consumption of those longer textual descriptions is
something that should be by choice). It also appears that this mechanism
should be available to a broader set of users than just those who are
non-sighted (ref: David's "people using" list)

David B. has suggested that "...the beauty of ARIA is that it is purely
annotative semantics that can be added to describe existing UI without
interfering with that UI." Put another way, ARIA should NOT be creating the
UI, simply mapping it. I will also note that this is fairly consistent with
the approach that NVDA takes, and specifically here with @longdesc: they are
not inclined to create a new UI control, they simply want to map to that
control.

I am not opposed to moving forward with an ARIA attribute that expresses the
semantic intent of the URI attached to it ("a long description of <this
image> is <over there>"), however until such time as the user-agents (and
specifically the browsers) actually create a UI control, it matters not
whether it is an ARIA attribute or a native HTML5 attribute: either will
fail. Further, even if we craft a new ARIA attribute that maps to such a UI
control, I personally cannot see why the @longdesc attribute could not also
be mapped to the same UI control for backward compatibility considerations.

JF

Received on Monday, 24 September 2012 20:12:59 UTC