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

I agree

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>

On Mon, Jul 11, 2016 at 11:40 AM, Jonathan Avila <jon.avila@ssbbartgroup.com
> wrote:

> Ø  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
>
> 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
>
>
>
> *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>
>
>
>
> On Wed, Jul 6, 2016 at 11:12 AM, John Foliot <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>
> 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
>
>
>