Re: (WCAG 2.1) Do we want to replace ​"programmatically determined link context" in 2.4.4 with "Accessible Name"?

I'm hoping to encourage some other means of determining the destination of
the link that it is *more* programmatically determinable than the paragraph
or sentence.

For a bit of history ... there were HUGE discussions about 2.4.4 in WCAG 2
formulation. A strong camp wanted the link text alone to determine the
destination. But there were compelling use cases not to *require* that. So
we set out to find an acceptable compromise. There was no wai aria during
these discussions around 2003.

John Slatin did some investigation and found that he could tab to a link,
and without moving he could get the screen reader to read the current
sentence or paragraph. I think Gregg came up with the phrase
Programmatically determined link context.

There was lots of discussion about lists of links in screen readers and
that this new term did not ensure that a list would have meaningful links.
But it was determined that the behaviour of AT was not the responsibility
of the group and that if AT is taking web content out of context to provide
a list of linksto blind people it was beyond the scope of what we should
require of authors to support.

Meanwhile, WAI ARIA came along to solve this and did so. It is mature and
supported

The thing I would like to encourage in this next version of WCAG is to
consider this new reality and ask ourselves if any of our decisions in WCAG
2 should be revisited in light of this.

WCAG is technology independent. So is WAI ARIA. It is a group of attributes
that can be added to any language... it just happens that HTML is the first
to fully adopt AIRA.

So the proposal is for us to look at this and see if we want to tweak
anything to discourage the clunky use of sentence and paragraph for link
context in favour of other means that are more likely to end up with better
accessibility for the end user. The current proposal is to amend the
definition of programmatically determined link text.


https://www.w3.org/WAI/GL/wiki/Modify_2.4.4_to_include_
Accessible_Name_for_link_destination

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 20, 2016 at 11:48 AM, Andrew Kirkpatrick <akirkpat@adobe.com>
wrote:

>
> *[Jason] yes, for standard components provided by a markup language it is
> already met. However, the issue here is whether making the purpose of a
> link clear by specifying an accessible name or description is enough to
> satisfy 2.4.4. 4.1.2 requires that it be present, but this doesn’t clarify
> the relationship with 2.4.4. “Link text” might not be the same as the label
> or description given to assistive technologies, as in the aria-label
> override example wehre the text of the link and the label given to AT are
> different.*
>
> That’s right.  4.1.2 requires a name, 2.4.4 requires that links provide
> useful information to convey the purpose of the link, either through the
> link text or from the programmatically determined information (including
> other forms of the accessibility name and other ways).
>
> I’m just not clear on what exactly needs to be fixed, and whether the
> driver for that change is end-user experience or comprehensibility for
> authors/evaluators.
>
> AWK
>