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

Ø  The thinking behind "ambiguous to all users" was intended to fill in a gap ... basically saying... if it's ambiguous to sighed users, where the context is not in the viewport  the viewport, then there is not requirement to make it accessible to screen reader users.

This has always been an unclear issue with SC 2.4.4.  That is on first read it sounds like it is about programmatic association which would primarily assist users who are blind.

But the non-normative understanding document (https://www.w3.org/TR/2013/NOTE-UNDERSTANDING-WCAG20-20130905/navigation-mechanisms-refs.html)  Goes on to main these benefits:
· This Success Criterion helps people with motion impairment by letting them skip links that they are not interested in, avoiding the keystrokes needed to visit the referenced content and then returning to the current content.
· People with cognitive limitations will not become disoriented by multiple means of navigation to and from content they are not interested in.

For benefit 1 above – how does a programmatic association help users with motor disabilities any more than the visual context of the link?  For benefit 2 above – seems like the benefit to users with cognitive disabilities here are only with assistive technology are used unless a technique like a title attribute or hover was used.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group
jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>
703.637.8957 (Office)
Visit us online: Website<http://www.ssbbartgroup.com/> | Twitter<https://twitter.com/SSBBARTGroup> | Facebook<https://www.facebook.com/ssbbartgroup> | Linkedin<https://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog/>
Check out our Digital Accessibility Webinars!<http://www.ssbbartgroup.com/webinars/>

From: David MacDonald [mailto:david100@sympatico.ca]
Sent: Wednesday, July 06, 2016 1:03 PM
To: John Foliot
Cc: WCAG
Subject: Re: Should 2.4.4 require Link text or ACCNAME, rather than enclosing sentence etc...

The thinking behind "ambiguous to all users" was intended to fill in a gap ... basically saying... if it's ambiguous to sighed users, where the context is not in the viewport  the viewport, then there is not requirement to make it accessible to screen reader users.

Putting aria-label="read more" would currently fail this SC unless there is no context in the visual viewport.

COGA is recommending one normative SCs that would address link destination.

​*​
Instructions, labels, navigation and important information are provided with a clear writing style that includes:
​ ... ​
"On controls, links and buttons use words that identify their function. Function can be the destination of a link (such as "home" or "contact us")"
https://www.w3.org/wiki/WCAG/Coga_SC


This seems identical to WCAG SC 2.4.9 Link Purpose (Link Only):

I think it would be difficult to elevate that to Level A or AA. But I've very open to exploring that with you if you'd like ...

COGA appear to acknowledge this, and is also proposing a coga-destination attribute, which is outside the context of WCAG SC's, and more along the lines of WAI ARIA attribute.
https://rawgit.com/w3c/coga/master/gap-analysis/#adding-context


We can't require something that doesn't yet exist. I think we can safely say that in this 2.1 version we should do an incremental change, and as the coga-destination attribute makes its way through the long and winding W3C process and then to user agent support, we can watch carefully and if it seems doable we can open the language further, in 2.4.4

I don't think this should reduce the functionality we'd like to provide to screen readers, which has been solved, with the addition of aria-label or labelledby.

Cheers,
David MacDonald



CanAdapt Solutions Inc.
Tel:  613.235.4902

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

twitter.com/davidmacd<http://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>

On Wed, Jul 6, 2016 at 11:12 AM, John Foliot <john.foliot@deque.com<mailto:john.foliot@deque.com>> wrote:
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<mailto: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



CanAdapt Solutions Inc.
Tel:  613.235.4902<tel:613.235.4902>

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

twitter.com/davidmacd<http://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<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion