Re: Checkpoint 13.1

>A and AREA elements that have a HREF attribute should also have a HREFLANG
>attribute. Valid values must be in the IANA registry (we have info about
>that somewhere else).

13.1 is a priority 2, but the checkpoint to identify the language of a 
document (4.3) is a priority 3.  Identifying changes in language within 
text (4.1) is a Priority 1.

I think this is most like Checkpoint 4.3 but fits best as a technique under 
13.1 but with priority 3 rather than 2.

However, we have already agreed that the Technique priority is inherited 
from the checkpoint priority.  Perhaps we should revisit that 
resolution?  or is this actually a priority 2 Technique?

Plus, I think this is a user agent issue.

>This brings to mind another technique that I thought I added to my
>submission over the weekend but must have been tired and forgot. We should
>also check for the TYPE attribute of A and AREA elements, wich identifies
>the MIME type, i.e., _computer_ "language", of the target. The advantage of
>this would be users (with browser support) would know not to follow links to
>images or whatever that put them in dead space.

hmm, again I think this is a user agent issue.  The resource that is being 
retrieved should identify itself.  For example, today I can tell Netscape, 
MSIE, and Opera not to load Java or scripts.

Your example, where I don't load an image because it will put me in "dead 
space" is interesting to consider.  If I have said not to load images, but 
I follow a link that bring up an image, then what will the browser do?
I created a test file to find out:

I turned off images in both Opera 3.6 and MSIE 5.  When I followed the 
link, both browsers did the same thing - showed the image.  I guess what 
else can they do?  There is no alt-text associated with it...

In the user agent guidelines, this is a priority 3:
8.4 Make available to the user information that will help the user decide 
whether to follow a link. [Priority 3]
Note. Useful information includes: whether the link designates an internal 
or external anchor, the type of the target resource, the length and size of 
an audio or video clip that will be started, and the expected natural 
language of target resource.

This takes me back to the discussion above....

Looking at 13.1 in WCAG again, using "title" is suggested, kind of like a 
P3.  There actually seem to be 2 checkpoints here:
WCAG 13.1 - Clearly identify the target of each link [Priority 2]
WCAG 13.1a - Provide supplemental information to help users determine if 
they want to follow the link. [Priority 3]  This includes: language of the 
resource, type of resource, size of resource, etc.

Therefore, I propose that we take this issue to WCAG WG.

wendy a chisholm
world wide web consortium
web accessibility initiative
madison, wi usa
tel: +1 608 663 6346

Received on Friday, 4 February 2000 14:30:58 UTC