Re: Should 2.4.4 require Link text or ACCNAME, rather than enclosing sentence etc...

Hi David,

I'm not sure that this solves the problem for all users, as the accessible
name is only being exposed to the accessibility API, and so does not solve
the problem for users who are not using a screen reader or other AT that
accesses that information. I think that the problem of vague links/link
text would likely also impact users with cognitive issues as well, and so
using ARIA alone to solve this problem is not a complete solution IMHO.

Equally, code that read "...aria-label="read more">" still has the same
over-arching problem: it's not that the link does not have an accessible
name, it's that the accessible name is not sufficient. So the 'clarity'
issue is as much editorial as it is programmatic. I would not be opposed to
adding more information via examples (as you are proposing), only that
using an ARIA solution alone does not really solve the larger issue - it's
more than just a screen reader issue.

Regarding 2.4.4, I think the actual problem (which I hope will be addressed
by the COGA folks) is this text: "...except where the purpose of the link
would be ambiguous to users in general." In other words, <a href=""
aria-label="read more about article X">Read more</a> still potentially
disadvantages some users, even if it improves things for the screen reader
user.

My $0.05 Cdn

JF

On Wed, Jul 6, 2016 at 9:45 AM, David MacDonald <david100@sympatico.ca>
wrote:

> 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>
>



-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion