- From: David MacDonald <david100@sympatico.ca>
- Date: Wed, 6 Jul 2016 13:03:09 -0400
- To: John Foliot <john.foliot@deque.com>
- CC: WCAG <w3c-wai-gl@w3.org>
- Message-ID: <BLU437-SMTP13D596A506BF55ED9B8FC1FE3A0@phx.gbl>
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 >
Received on Wednesday, 6 July 2016 17:03:43 UTC