RE: CP, ISSUE-30: Link longdesc to role of img [Was: hypothetical question on longdesc]

Silvia Pfeiffer wrote:
> 
> Just to make this clear: I have listened to blind users. I am well
> aware of the need to describe the poster and I have made a suggestion
> for how to do this with existing markup. I have then spoken again to
> more technically-involved blind users that have agreed - no, more so:
> suggested - that @aria-label is a sufficient for description of a
> video poster.

It isn't, and here's why:

	1) The <video> element, when containing both a media asset and an
image, now has 2 objects that require a longer textual description. Any
attribute assigned to an element is an attribute of *that element*, and
cannot be attached to another attribute: in other words you cannot assign an
attribute, even an aria-attribute, to the attribute of @poster, only the
element of <video>. This is why I had originally investigated creating a new
<poster> element (as a child of <video>) - but that met resistance.

	2) Further, if you add aria-label to the <video> element, are you
labeling the video file or the image file? There is currently no way of
programmatically determining which visual asset you are "naming" - but I
would suggest that when having to decide, the media asset would likely take
precedence over the JPG file, which would be a logical assumption. You
cannot apply two instances of aria-label to an element, only 1, so you have
a problem there too.

	3) aria-label maps to the Accessibility API property of accName
[accessible name]
(http://www.w3.org/WAI/PF/aria-implementation/#mapping_state-property_table)
used in calculating the accessible name as described in Name Computation
(http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd). 

We aren't seeking a "name" here (and specifically not an 'accessible name',
which is usually related to controls), instead we are looking for a
description. 

	4) It gets worse however, as the ARIA Name Computation states:

	"If aria-labelledby is empty or undefined, the aria-label attribute,
which defines an explicit text string, is used." - Explicit Text String (I'm
not making this up!)

For this reason aria-label *CANNOT* support rich (HTML) text, because the
ARIA Specification specifically and precisely states that it cannot - it
gets flattened to string text. Aria-label was created to map to the
Accessibility APIs, so that widgets could have an accessible name - those
APIs have no need or even concept of "richer" text.

Thus, using aria-label does not meet the need of allowing for a longer
textual description to describe the @poster image, as we need the ability to
use rich text, say for example in support of internationalization needs. 

(Use case: <span lang="fr">Dīner pour deux</span>: A Foreign Film -
http://www.imdb.com/title/tt1890389/ - and that's just the short text name,
not a longer description.) 

This is the very same reason why aria-describedby cannot point to "hidden"
text, as it too will be flattened to the same string text, using the same
computational rules.

	5) Finally, because the accessible name is critical for non-sighted
users to interact with screen widgets, the accessible name is automatically
read aloud by screen-readers. However, users should have the *choice* to
hear the extended textual description of the poster, and not have it forced
upon them without being asked. This becomes a significantly poorer
user-experience as the textual description gets longer, and it would not be
unreasonable to see more than just a single sentence or even paragraph to
describe a complex image.  

All of this has been discussed before, both in the context of a longer
textual description for the @poster image, as well as in context to the
various ideas surfacing around @longdesc (which adds to my personal
frustration, as this has all been carefully and explicitly documented to the
Working Group numerous times, yet there seems to be an almost selective
hearing loss there).


> Your argument continues to circle around the first fact that we need a
> description for poster. I do not reject that need. I have found a
> workable solution.

Sadly, while your proposal perhaps looks good on paper at first glance, it
wilts under scrutiny - see above.


> You will always be able to find mis-markup
> (including bad choices of poster images) that will not follow the
> intent of the spec, but riding on that fact gets you nowhere. Any
> attribute and element can be misused. What we need to find a solution
> for is the good case where the developer does what is expected of
> them. And we have a solution for that case. So, for me that is a
> problem solved.

Except, it isn't. 

Silvia, it would have been my preference to see a new native attribute or
element added directly to HTML5 to address this need, but I was unsuccessful
in that effort. 

Last November at the TPAC Face-to-Face I spent close to 90 minutes in direct
1-on-1 discussion with Rich Schwerdtfeger exploring this need with existing
markup possibilities, both in HTML5 and with ARIA, and at the end of that
exercise he conceded that yes, we need to craft something new, as nothing
currently in ARIA 1.0 would solve the use-case or problem. 

This has lead to the introduction of creating a new ARIA attribute in ARIA
1.1 to meet this need. Work has not yet started in earnest however as the
ARIA-WG is working at getting ARIA 1.0 "out the door", a non-trivial effort.
The working list of proposed new ARIA 1.1 attributes is sadly confined at
this time to the PFWG member-only work space, but I will work to see it that
list cannot be made more public.

Can this problem be solved via ARIA? Likely, but not yet, as there is
nothing inside of ARIA that allows for the user requirements that have been
identified. That gap is going to be met soon enough, but is not yet met
today. I urge you to read up more on the ARIA Specification, Implementation
Guide, and to query any member of the ARIA-WG if you question any of my
assertions here - but please trust me when I say I've invested a lot of time
examining if and how ARIA could work to solve this problem already.


> > Suggesting that non-sighted users don't need, or won't require a
> means of
> > understanding what that expensive image will be is both unfair and
> > unrealistic.
> 
> That is a mis-characterisation of what I am saying.

You are correct, although suggesting that it is an icon is very close to
that. Others have said it more forcefully in the context of the many, many
discussions that have focused on this need. 

JF

Received on Wednesday, 21 March 2012 06:19:47 UTC