RE: Re[2]: (WCAG 2.1) Do we want to replace ​"programmatically determined link context" in 2.4.4 with "Accessible Name"? - NEW Should we leverage AAPIs?

To the original point, as I stated, we would still have to address the 'in
context' part of 2.4.4.

But to AAPIs, they actually *can* be leveraged to support more kinds of
users of AT, and, it doesn't preclude additional support for users who
don't use AT.

My point is, we should be addressing this in WCAG 2.1, IMHO, as changing
AAPIs (at the platform level) is a lot easier than teaching all developers
about using semantic html, css, and scripting correctly - and ARIA - and
WCAG.

Urging - 4 or 5 platform AAPIs (large companies w $) vs all developers -
seems like an easier direction to start moving towards.

As far at AT-only leveraging AAPIs - every browser passes through this
information.

AAPIs provide additional information about a 'thing' and how to interact
with such 'thing' - that both platforms and browsers (including AT)
utilize.

Platform manufactures (Apple, Microsoft, etc) and browser manufactures,
including AT - can move much faster than W3C standards development and
developers learning and implementing those standards.

I am suggesting we start to push accessibity in this direction. It doesnt
mean we stop HTML, WCAG or ARIA continued development.

You know that thing about 'the tools working for us' - as much as possible
- we should try to leverage and guide AAPI development to support
cognitive, low vision, etc. -  user needs.

AAPIs currently have rich vocabularies. I am suggesting we use and guide
them to solidify and enrich html and scripting languages to utilize them
more.

Microsoft recently revamped their AAPI, and see how well Narrator is doing.
So much easier than teaching all developers how to bootstrap for IE or
Edge....

Katie Haritos-Shea
703-371-5545

On Jul 19, 2016 4:18 PM, "John Foliot" <john.foliot@deque.com> wrote:

Hi Katie,



Actually, I think it’s the other way ‘round: Assistive Technologies draw
the abstracted Role, State, and Property(ies) from the Accessibility APIs,
and ARIA is a means of providing information about the content **to** the
Accessibility API when that information is not natively exposed through the
host mark-up language (i.e. <button> and <div role=”button”> are both
exposed as buttons in the AAPI).



The larger point however is that the Accessibility APIs don’t always
provide a solution to all users with disabilities, only to those users who
rely on tools that access the AAPI. The current “programmatically
associated” phrase that kicked off this thread can go beyond just
“Accessible Name” or any other AAPI construct, and so again swinging back
to the original topic, I would be opposed to replacing ​"programmatically
determined link context" in SC 2.4.4 with "Accessible Name" in WCAG 2.1



JF



*From:* Katie Haritos-Shea [mailto:ryladog@gmail.com]
*Sent:* Tuesday, July 19, 2016 3:08 PM
*To:* John Foliot <john.foliot@deque.com>
*Cc:* David MacDonald <david100@sympatico.ca>; Joshue O Connor <
josh@interaccess.ie>; WCAG <w3c-wai-gl@w3.org>; Wayne Dick <
wayneedick@gmail.com>
*Subject:* Re: Re[2]: (WCAG 2.1) Do we want to replace ​"programmatically
determined link context" in 2.4.4 with "Accessible Name"?



Accessibility APIs expose accessible name, description, etc. ARIA draws
upon those components in AAPIs.

So, it isnt just about the term Accessible Name, it is about all of the
AAPI components.

Katie Haritos-Shea
703-371-5545



On Jul 19, 2016 3:27 PM, "Katie Haritos-Shea" <ryladog@gmail.com> wrote:

Yes, that right (nice to see you looked that up JF...:-)

I actually think we do *need* to include and address AAPI access,
differentiated from ARIA (not instead of - its not an either/or
distinction), and how semantic html can use, expose and leverage these
components. AAPIs are *not* inherently blind- centric and can be leveraged,
as well as ARIA if desired.

The advantage of leveraging AAPIs is that they provide the rationale and
natural mapping for good semantics in html. And they inherently do deal
with interactivity.

Katie Haritos-Shea
703-371-5545



On Jul 19, 2016 3:09 PM, "John Foliot" <john.foliot@deque.com> wrote:

Yep, Accessible Name originally derived from MSAA, which was the first
accessibility API that assistive technology could rely upon. I think the
point that Wayne was making is that the accessibility APIs do not address
all accessibility issues, and limiting ourselves to a term that is very
AAPI specific may, as Gregg noted, actually be more limiting in scope and
restrict potential solutions going forward.



JF



On Tue, Jul 19, 2016 at 1:54 PM, David MacDonald <david100@sympatico.ca>
wrote:

That's right Katie



The Accessible Name comes from the accessibility API rather than the
language ARIA that talks to the API. A regular HTML form label has an
Accessible Name. A bit of history is here

https://www.smashingmagazine.com/2015/03/web-accessibility-with-accessibility-api/




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 Tue, Jul 19, 2016 at 2:08 PM, David MacDonald <david100@sympatico.ca>
wrote:

Jason has an important concern, that we would have to provide a way for
authors to provide context when it is useful rather than a verbose
accessible name...



I also wonder about the familiar pattern on many home pages:



Linked heading to an article

Teaser sentence or paragraph summarizing or starting the article

"read more" link to same page as the heading



In the links list you get something like this:



Sun is shining over WCAG

Read More

Mobile Task Force getting along wonderfully

Read more

Cognitive task force make great progress

read more



I currently don't know how much of a problem that is... would it be better
like this using labelledby?



Sun is shining over WCAG

Read More Sun is shining over WCAG

Mobile Task Force have joyful call together

Read more Mobile Task Force getting along wonderfully

Cognitive task force make great progress

read more Cognitive task force make great progress


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 Tue, Jul 19, 2016 at 12:30 PM, John Foliot <john.foliot@deque.com> wrote:

Sure, but I also agree with Wayne.



I loves me the ARIA, but it is mostly targeted to screen reader users, and
we need to remember other user-groups as well. I would be in favor of *
*adding** Accessible Name, but we must recognize that it is but a reference
to the ARIA API mappings. I wonder aloud how many mainstream developers
even know that term today…



I think I would be opposed to simply swapping out one term/phrase for the
other.



JF



*From:* josh@interaccess.ie [mailto:josh@interaccess.ie]
*Sent:* Tuesday, July 19, 2016 11:27 AM
*To:* Wayne Dick <wayneedick@gmail.com>; David MacDonald <
david100@sympatico.ca>
*Cc:* WCAG <w3c-wai-gl@w3.org>
*Subject:* Re[2]: (WCAG 2.1) Do we want to replace ​"programmatically
determined link context" in 2.4.4 with "Accessible Name"?



I also think the terms are too similar - but I know where David is coming
from with this.



Thanks



Josh



------ Original Message ------

From: "Wayne Dick" <wayneedick@gmail.com>

To: "David MacDonald" <david100@sympatico.ca>

Cc: "WCAG" <w3c-wai-gl@w3.org>

Sent: 19/07/2016 17:07:07

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



I hope you don't mean the accessible name as in the accessible name
computation in ARIA 1.0 and 1.1.  That is out of the frying pan into the
fire.

Wayne



On Tue, Jul 19, 2016 at 6:13 AM, David MacDonald <david100@sympatico.ca>
wrote:

***This is proposed for version 2.1. NOT for 2.0 ***



Do we want to consider replacing

​"

programmatically determined link context" with "Accessible name" in 2.4.4.



This will simplify the requirement, eliminate that awkward definition that
few developers understood, and ensure that when screen reader users pull up
a list of links on on conforming page, they will not get "learn more"
etc... because screen readers provide the accessible name in the links
list, not just the link text. So an aria-label or aria-labelledby will
render a meaningful text in the list. AccessibleName wasn't well understood
or supported back in 2006-2008.



===Current===

2.4.4 Link Purpose (In Context): The purpose of each link can be determined
from the link text alone or from the link text together with its

​​

programmatically determined link context, except where the purpose of the
link would be ambiguous to users in general. (Level A)



​=== Proposal change===


2.4.4 Link Purpose (In Context): The purpose of each link can be determined
from the link text alone or Accessible Name, except where the purpose of
the link would be ambiguous to users in general. (Level A)



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>

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 Tuesday, 19 July 2016 21:10:12 UTC