Re: Consensus on longdesc change proposal

On Tue, 31 May 2011 15:27:04 +0200, Laura Carlson  
<laura.lee.carlson@gmail.com> wrote:

> Hi Chaals,
>
> On 5/30/11, Charles McCathieNevile <chaals@opera.com> wrote:
>> On Thu, 26 May 2011 02:50:15 +0200, Silvia Pfeiffer
>> <silviapfeiffer1@gmail.com> wrote:

> Do you think that anything in the ARIA section [1] of the change
> proposal should be reworded to make it clearer?

Yes:

> If so, can you suggest specific verbiage?

Hmm.

I would suggest restructuring the list of problems, first to remove  
redundancies, and then to provide a table since many of the same problems  
apply to many of the proposed alternatives...

I would also suggest noting the likelihood of given alternatives being a  
feasible long-term replacement - I think this can happen if aria version 2  
is different, whereas I think the other proposals are simply non-starters.

Notes on the redundancies follow this suggested rewording of the list:

=== The proposed alternative is not a functional replacement for longdesc  
===

* The alternative requires particular necessary content to be included in  
a given page. While it is a good practice to avoid 'hidden metadata' in  
many cases, attempts to require this authoring behaviour by specification  
are doomed to failure. Indeed, since features as microdata are  
specifically designed to make it possible to carry hidden metadata we can  
expect authors to simply use a range of ambiguous techniques to provide  
this data.
* The alternative does not support the re-use of a description for an  
image which is present on more than one page.
* The alternative does not support anything richer than plain text. This  
significantly reduces the author's ability to provide a rich, navigable  
hypertext description, something that longdesc readily supports.
* The alternative proposes a new way to solve something where there is an  
existing answer. This breaks the guideline of "paving cowpaths", and if it  
were to be carefully followed breaks both compatibility with existing best  
practice (and documentation of the same), as well as requiring a range of  
tools, content, and authoring guidance to be updated in order to achieve  
compatibility with the replacement - for something meant to solve the same  
problem, this is an unacceptable cost.
* The alternative forces people to read another large specification. This  
reduces the chances that it will be effectively implemented, by  
significantly increasing the workload required to understand the new model.

...and my notes on the current list for aria-describedBy;

> aria-describedby is not a functional replacement for longdesc.

This is a header.

>   aria-describedby natively forces a visual encumbrance on sighted  
> users. Many artists, designers, marketers, and authors do not want their  
> visual designs changed/ruined with redundant text.

If you insist on trying to use it as a near-functional replacement, this  
is one of the problems with it as a replacement as-is.

>   aria-describedby cannot provide one common off page description for  
> the same image repeated on several pages when that image also serves as  
> a link. (i.e. it lacks the ability for an image to appear on multiple  
> pages throughout a site or throughout multiple sites or from an HTML  
> email while at the same time linking to one longdesc document).

This is a second problem. Actually, it can't provide a description for  
things not part of the same page, period.

>   aria-describedby will annotate text in the target id referenced by the  
> idref. This means assistive technology users would not be able to  
> control how they interact with the long description (as they can with  
> longdesc). It is read aloud without any user intervention, forcing the  
> longer description on the user whether they want it or not. ...

I believe this is an implementation decision that doesn't have to be made  
this way, so think it should be removed.

> ... The target provided by the idref is concatenated to the  
> "description" property in the accessibility API, which means AT users  
> receive that information as a string of text. This is outside of ATs'  
> control, so they have no choice but to announce it as a string, rather  
> than allow the user to navigate the content using reading keystrokes to  
> investigate rich semantics.

This is a third problem.

>   As, by definition, a long description is in fact long,  
> aria-describedby is not good solution for a longdesc because semantic  
> elements are better for users than having a long stream of text  
> announced to them. With semantic elements, the user is able to control  
> how that content is delivered; with a text string, it's delivered as one  
> long stream.

This is a restatement of the third problem.

>   aria-describedby is limited to text that appears in the same document  
> as the image being described.

This is a restatement of problem 2

>   The content associated using aria-describedby as currently  
> implemented, is limited to unstructured text. AT treats aria-describedby  
> target content as though it does not have any mark-up. It is treated as  
> a string of text.

This is a restatement of problem 3.

>   aria-describedby is not backwards compatible. Unlike longdesc,  
> aria-describedby would not be recognized by existing authoring tools,  
> user agents, assistive technologies, educational material, etc. longdesc  
> has a critical support base that has taken a decade to build and would  
> probably take another to rebuild with a new element. Obsoleting longdesc  
> in favor of a aria-describedby would setback progress.

This is a fourth problem, although a relatively minor one given the poor  
implementation to date. It may be the case that getting accessibility  
features well implemented is very hard, so slow progress is the norm. In  
that case, expectations that a new improved solution would be implemented  
faster are likely over-optimistic.

>   aria-describedby kills off links: ARIA 1.0 specifies that anything  
> that aria-describedby points to is presented to the user as if it  
> occurred inside an attribute. Hence, if aria-describedby points to an  
> element which is - or contains - a link, the link will be completely  
> dead - the AT won't even inform the user about the link presence.

This is a particular implication of problem 3 that I don't think adds much.

>   aria-describedby is not native HTML. Protocols and Formats Working  
> Group (PFWG) "likes the idea of having built in semantics in HTML and in  
> particular would prefer to have common document elements."

This is a fifth problem, but very minor indeed.

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Tuesday, 31 May 2011 18:20:05 UTC