WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Link purpose (WCAG)

for

From: Olaf Drümmer
Date: Jul 22, 2013 12:09PM


Hi Andrew,

just looking at PDF techniques for links I realise again how many technically incorrect pieces of information there are in the PDF techniques. In this specific case the PDF Technique "PDF13: Providing replacement text using the /Alt entry for links in PDF documents" is already getting things wrong in its title: replacement text, as defined in ISO 32000-1 14.9.4, is about the ActualText attribute, not the Alt attribute - which is talked about in the technique. And actually should not be used at all here, as far as I can tell, because the PDF standard as well as the PDF/UA standard explicitly make it clear that if an alternative description is to be provided for an annotation (which would include Link annotations) then it has to be done through the Contents entry of the annotation/Link. As a consequence the technique is inverting users to violate the PDF standard. And replacement text as well would be wring - because it is just that: it would replace the Link by some text. This implies that the link would disappear from the logical structure….

What is the right approach to get the PDF techniques fixed?

Olaf


Am 22 Jul 2013 um 18:57 schrieb Andrew Kirkpatrick < <EMAIL REMOVED> >:

> What JAWS does do, at least when I hit Ins+T (JAWSKEY+T) is read the title of the page and then it reads the immediate heading preceding the current location for the user.
>
> As Birkir points out, there are other ways to address this success criteria also.
>
> I will point out that there is nothing that states that the user must never need to move their focus from the link. The Understanding document (which is non-normative) says that the user _should_ be able to determine this without moving their focus from the link, and the JAWS keystroke helps make this possible if the context is available via the preceding heading, but it can also be met via other means such as when words in the sentence containing the link provide the context. A screen reader user who tabs to a link that doesn't make immediate sense may need to arrow up and down to read the line where the link is found to see if it makes sense. From conversations and observations of assistive technology users, this seems reasonable (speak up if you disagree!). To get the link itself to provide all of the context in the link text, SC 2.4.9 (http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-link.html) is the triple A criteria that applies.
>
> Thanks,
> AWK
>
> Andrew Kirkpatrick
> Group Product Manager, Accessibility
> Adobe Systems
>
> <EMAIL REMOVED>
> http://twitter.com/awkawk
> http://blogs.adobe.com/accessibility
>
>
> -----Original Message-----
> From: <EMAIL REMOVED> [mailto: <EMAIL REMOVED> ] On Behalf Of Birkir R. Gunnarsson
> Sent: Monday, July 22, 2013 10:39 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Link purpose (WCAG)
>
> I have always found this wording to be confusing myself, and JawsKey-T will never work, I guess the thought is that it would read the title of the link (often links with identical text use their title attribute for clarifying information), but Jaws does not do this.
> It will speak the title if explicitly told to do so, but it is not a default setting.
> I usually advocate, within reasonable limits, to use aria-describedby to satisfy this success criteria:
> http://oaa-accessibility.org/example/44/
> Cheers
> -Birkir
> Birkir Gunnarsson | Accessibility Subject Matter Expert Deque Systems
>
>
> On 7/22/13, Gijs Veyfeyken < <EMAIL REMOVED> > wrote:
>> Hi,
>>
>> I'm well aware one should always use links that are meaningful without
>> context.
>> But according to WCAG level A, it's allowed in meaningful context,
>> such as the preceding heading.
>>
>> WCAG Success Criterion 2.4.4 (Link Purpose (In Context)) states:
>> "The purpose of each link can be determined from the link text alone
>> or from the link text together with its programmatically determined link context"
>> http://www.w3.org/TR/2008/REC-WCAG20-20081211/#navigation-mechanisms-r
>> efs
>>
>> Understanding SC 2.4.4. specifies "programmatically determined link
>> context":
>> "the user should be able to identify the purpose of the link without
>> moving focus from the link.
>> In other words, they can arrive on a link and find out more about it
>> without losing their place.This can be achieved by putting the
>> description of the link in the same sentence, paragraph, list item,
>> the heading immediately preceding the link, or table cell as the link,
>> or in the table header cell for a link in a data table, because these
>> are directly associated with the link itself."
>> http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-refs.h
>> tml
>>
>> "the heading immediately preceding the link" can be considered as context.
>>
>> However, it's not possible to read the heading immediately preceding
>> the link with a screenreader without moving the focus, by my knowledge.
>>
>> Technique H80 (Identifying the purpose of a link using link text
>> combined with the preceding heading element) states:
>> "The command to take advantage of this technique in JAWS is "JAWS KEY
>> + T"."
>> http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/H80
>>
>> Jaws Key + reads the title of the page <title>, not the first heading
>> <h> above the focus.
>> Am I missing something or is this a mistake in WCAG?
>>
>> Kind regards,
>>
>> Gijs
>>
>> ---
>> Gijs Veyfeyken
>> AnySurfer - towards an accessible internet http://www.anysurfer.be/en
>> <EMAIL REMOVED>
>>
>>
>>
>> >> >> list messages to <EMAIL REMOVED>
>>
> > > > >