- From: Katie Haritos-Shea <ryladog@gmail.com>
- Date: Tue, 19 Jul 2016 17:09:38 -0400
- To: John Foliot <john.foliot@deque.com>
- Cc: WCAG <w3c-wai-gl@w3.org>, Joshue O Connor <josh@interaccess.ie>, David MacDonald <david100@sympatico.ca>, Wayne Dick <wayneedick@gmail.com>
- Message-ID: <CAEy-OxGhzht0QeojWCQhjWXDbydxz+X6LCaGN2j9Krt+edvZtQ@mail.gmail.com>
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