Should SC 2.4.4 require Link text or Accessible Name, rather than enclosing sentence etc.?

I think now that there is easy technology to provide an accessible name
that describes the destination of a link, we should consider removing the
"link in context" exception from 2.4.4.

In WCAG 2, we originally wanted a screen reader user to be able to pull up
a list of links and know where they all go. But a compromise was reached
when John Slatin said "I can, if necessary, hear the whole sentence in JAWS
without moving focus from the link"

With that was born the idea the programmatic determination included the
sentence, the table cell of a row etc, that we find currently in WCAG 2.
Unfortunately, our definition never  solved the problem of a screen reader
user pulling up a list of links and seeing "learn more", "read more" etc...

WAI Aria has solved the issue, with aria-label, and aria-labelledby which
show up in links list in Screen Readers.

We can solve this in 2.1 by removing the example and in the understanding
make it clear that "presented to users in different modalities" means the
Accessible Name.


​===​
programmatically determined link context
​===​


additional information that can be programmatically determined from
relationships with a link, combined with the link text, and presented to
users in different modalities

Example: In HTML, information that is programmatically determinable from a
link in English includes text that is in the same paragraph, list, or table
cell as the link or in a table header cell that is associated with the
table cell that contains the link.

Note: Since screen readers interpret punctuation, they can also provide the
context from the current sentence, when the focus is on a link in that
sentence.


​===​
programmatically determined (programmatically determinable)
​===​


determined by software from author-supplied data provided in a way that
different user agents, including assistive technologies, can extract and
present this information to users in different modalities

Example 1: Determined in a markup language from elements and attributes
that are accessed directly by commonly available assistive technology.

Example 2: Determined from technology-specific data structures in a
non-markup language and exposed to assistive technology via an
accessibility API that is supported by commonly available assistive
technology.




Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*
Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>