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

>The accessible name or description is not 'linked context' the term the
definition covers ...

The Accessible Name and description are attributes on the enclosing element
of the link (anchor tag), which is programmatically determinable, and they
are presented to the user. Saying a modification to a definition doesn't
fit the definition is a weird circle of logic. That's the point of a new
version. To open things up and update.

At any rate... I can see very little momentum for this proposal which,
according to the people I teach, would help improve link text for beginner
and intermediate blind screen reader users.

So let us make a consensus statement.

"There will be no modifications to the requirements or definitions of SC
2.4.4 in this update."

I consider this thread closed.

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 Fri, Jul 22, 2016 at 2:36 PM, Sailesh Panchang <
sailesh.panchang@deque.com> wrote:

> Hi David,
> Adding what you suggest to the definition for 'PD linked context' is
> questionable.
> The accessible name or description is not 'linked context' the term
> the definition covers ... those words you propose to add describes
> what PD means.
> The term 'PD linked context' follows the term PD in the list of
> definitions and in fact links to that definition too.
> If you wish, a clarification may be  added to the Understanding doc
> explaining the different methods  by which the linked context can be
> made PD. I am not in favor of tinkering with the normative content as
> proposed.
>
> Thanks and regards,
> Sailesh
>
>
> On 7/22/16, David MacDonald <david100@sympatico.ca> wrote:
> > The purpose of the thread was to explore our willingness to strengthen
> > 2.4.4 more in line with the two fold original purpose of its predecessor
> in
> > WCAG 1 1998. I'm dating myself here but here is where WCAG2 SC 2.4.4 came
> > from.
> >
> > ​WCAG version 1 section ​
> > 13.1
> > ​'
> > Clearly identify the target of each link. [Priority 2]
> > ​ ​
> > Link text should be meaningful enough to make sense when read out of
> > context -- either on its own or as part of a sequence of links....For
> > example, in HTML, write "Information about version 4.3" instead of "click
> > here". ...
> > ​'​
> >
> >
> > This is the genesis of 2.4.4
> > ​ which was formed in about 2003​
> > , where we added the concept of "programmatically determined link
> context"
> > ​ ​
> > which was a compromise because ​links lists in screen readers didn't
> > present "programmatically determined link context " and still don't.
> > However, they do present the Accessible Name. (They don't present the
> > accessible description). Links lists help beginner and intermediate
> screen
> > reader users, and are not generally used advanced users like yourself or
> > Jason.
> >
> >
> > After considering the concerns raised in this thread the current proposal
> > is very modest. Simply add this phrase to the definition of
> > "programmatically determined link context".
> >
> > "This could also be in the accessible name or accessible description​."
> >
> >
> 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 Thu, Jul 21, 2016 at 5:47 PM, Sailesh Panchang <spanchang02@yahoo.com
> >
> > wrote:
> >
> >> Title serves as a name in cases like H65 or when  a close -X link
> >> rendered
> >> via CSS relies on title.  But this is not being suggested in above
> >> emails.
> >>
> >> Sailesh. ...Sent from my iPhone
> >>
> >> > On Jul 21, 2016, at 5:28 PM, Patrick H. Lauke <redux@splintered.co.uk
> >
> >> wrote:
> >> >
> >> >> On 21/07/2016 22:11, Sailesh Panchang wrote:
> >> >> Patrick,
> >> >> The page you reference clearly distinguishes accessible-name and
> >> >> accessible-description as two properties.
> >> >> I do not see how you conclude, "title, aria-describedby etc all form
> >> >> part of what's taken into consideration for the accessible name
> >> >> calculation".
> >> >
> >> > I tripped up on the aria-describedby...however, "title" does form part
> >> of the accessible name calculation.
> >> >
> >> > For instance, for input, the UA does the following to determine the
> >> accessible name (note point 5):
> >> >
> >> > 1. Use aria-labelledby
> >> > 2. Otherwise use aria-label
> >> > 3. Otherwise use the associated label element
> >> > 4. Otherwise use the placeholder attribute
> >> > 5. Otherwise use the title attribute
> >> > 6. If none of the above yield a usable text string there is no
> >> accessible name
> >> >
> >> > P
> >> > --
> >> > Patrick H. Lauke
> >> >
> >> > www.splintered.co.uk | https://github.com/patrickhlauke
> >> > http://flickr.com/photos/redux/ | http://redux.deviantart.com
> >> > twitter: @patrick_h_lauke | skype: patrick_h_lauke
> >> >
> >>
> >>
> >>
> >>
> >
>
>