RE: Proposed APG usage statement and GitHub response

+1

From: James Nurthen <nurthen@adobe.com>
Sent: Wednesday, November 14, 2018 5:42 PM
To: Siri Gubba (Artech Consulting LLC) <v-shgubb@microsoft.com>; Ku, JaEun Jemma <jku@illinois.edu>; Ann Abbott <annabbott@gmail.com>
Cc: McCarthy, Mark C <mcmccar2@uillinois.edu>; public-aria-practices@w3.org
Subject: Re: Proposed APG usage statement and GitHub response

Can we add some of Mark’s response. The generic response from Bryan doesn’t really address why we might be closing any specific issue. While this is much longer than I had hoped how about the following combination:


It is important to note that the intended purpose of the Authoring Practices Guide, is to provide general design patterns for common widget types that utilize ARIA to enhance their functionality in accordance with the ARIA specification. In many cases, these code examples are deliberately simplistic to allow for easy modification and enhancement by developers, and to better illustrate important concepts within the coding process where ARIA is involved.

The Authoring Practices Guide is not meant to represent all possible usages of ARIA, nor to cover all possible variations of specific widget types, but rather, to establish common usage patterns that demonstrate where and how specific ARIA roles and attributes should be used within the confines of a specific design pattern and usage paradigm. While we’d like to help as much as we can, we aren’t able to comment on specific app and/or program implementations. We simply don’t have the resources to do so. However, there are some places online you can look! You might be able to use the Mozilla Developer Network (link), reach out on the Web A11y Slack channel (link), and perhaps Stack Overflow (link) (though you might want to double check some of the solutions you find there). Best of luck with your build!


(Optionally add the following statement if relevant to the question.)
Additionally, the Authoring Practices Guide intentionally does not represent ARIA widgets that are universally supported by assistive technologies, but rather, is meant to provide a functional archive of common widget types that should be used by assistive technology providers to test against to ensure future conformance. For this reason, comprehensive testing with assistive technologies should always be performed when implementing any ARIA design pattern within production environments for public usage, to ensure that the design pattern being implemented is sufficiently supported to ensure accessibility.



James Nurthen  |  Accessibility Engineer  |  Adobe  |  p. 415.832.2734  |  c. 415.987.1918  |  nurthen@adobe.com<mailto:nurthen@adobe.com>



From: "Siri Gubba (Artech Consulting LLC)" <v-shgubb@microsoft.com<mailto:v-shgubb@microsoft.com>>
Date: Wednesday, November 14, 2018 at 6:48 AM
To: "Ku, JaEun Jemma" <jku@illinois.edu<mailto:jku@illinois.edu>>, Ann Abbott <annabbott@gmail.com<mailto:annabbott@gmail.com>>
Cc: "McCarthy, Mark C" <mcmccar2@uillinois.edu<mailto:mcmccar2@uillinois.edu>>, "public-aria-practices@w3.org<mailto:public-aria-practices@w3.org>" <public-aria-practices@w3.org<mailto:public-aria-practices@w3.org>>
Subject: RE: Proposed APG usage statement and GitHub response
Resent-From: <public-aria-practices@w3.org<mailto:public-aria-practices@w3.org>>
Resent-Date: Wednesday, November 14, 2018 at 6:48 AM

I agree with Jemma.
Bryans response talks about what the Authoring Practices Guide is meant for.


Thanks,
Siri

From: Ku, JaEun Jemma <jku@illinois.edu<mailto:jku@illinois.edu>>
Sent: Wednesday, November 14, 2018 12:13 AM
To: Ann Abbott <annabbott@gmail.com<mailto:annabbott@gmail.com>>
Cc: McCarthy, Mark C <mcmccar2@uillinois.edu<mailto:mcmccar2@uillinois.edu>>; public-aria-practices@w3.org<mailto:public-aria-practices@w3.org>
Subject: Re: Proposed APG usage statement and GitHub response

Actually, I prefer Bryan’s response since these are the ideas/consensus/summary we as a group have discussed over the years.

Only one thing is I would like to comment is below sentence because it can misleading due to the words, “intentionally” and “universally”. Bryan’s intention for this sentence is to share the reality that Authoring Practice Guide working group can not control the AT Implementation. Is that correct, Bryan?

Additionally, the Authoring Practices Guide intentionally does not represent ARIA widgets that are universally supported by assistive technologies,
Best,
JaEun Jemma Ku

Sent from my iPad

On Nov 13, 2018, at 10:01 PM, Ann Abbott <annabbott@gmail.com<mailto:annabbott@gmail.com>> wrote:
Bryan and Mark -

I think these responses are spot on! And quite eloquent! Thank you for your time and effort on behalf of the Working Group.

Kind Regards,
Ann
annabbott@gmail.com<mailto:annabbott@gmail.com>
512-451-8267


On Tue, Nov 13, 2018 at 2:19 PM McCarthy, Mark C <mcmccar2@uillinois.edu<mailto:mcmccar2@uillinois.edu>> wrote:
That’s a great response to that specific question Bryan!

Here’s something simple I thought of  that might be even more general as a future group response to questions like these:

“As a group, we’d recommend making sure to read the authoring practices guide in depth. That will provide the deepest help to you. While we’d like to help as much as we can, we aren’t able to comment on specific app and/or program implementations. We simply don’t have the resources to do so. However, there are some places online you can look! You might be able to use the Mozilla Developer Network (link), reach out on the Web A11y Slack channel (link), and perhaps Stack Overflow (link) (though you might want to double check some of the solutions you find there). Best of luck with your build!”

Thoughts? We could of course change up the resources suggested or change them up based on time/relevance/specificity.
mark

___
Mark McCarthy, IADP, MSIM
QA Engineering, AITS | University of Illinois
pronoun.is/he?or=they<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpronoun.is%2Fhe%3For%3Dthey&data=02%7C01%7Cv-shgubb%40microsoft.com%7C327592643a9246d5927c08d649f83cf3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636777727859435768&sdata=utlw258JWS5JYqqP0KG%2BbmAUb3ojJO5NLenO2czVHxw%3D&reserved=0>
Phone: 217-300-3408<tel:217-300-3408>
“Knowing is not enough, we must apply. Willing is not enough, we must do.” - Bruce Lee



From: Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>
Sent: Tuesday, November 13, 2018 12:31 PM
To: public-aria-practices@w3.org<mailto:public-aria-practices@w3.org>
Subject: Proposed APG usage statement and GitHub response

Hi,
I didn't have time to finish the general support statement yesterday, but I've done so below for review.

First, about the questions in the GitHub thread, I'd recommend the following as answers. I wasn’t sure where other general usage guidance is located, so please edit as needed.

*** From GitHub thread ***

"If I was to build a layout design tool such as sketch/photoshop in the web, what sorts of aria attributes would I use to tell the user if they press an arrow key that a new layer would be selected."

There are various attributes that may help with this, the most supported at present being aria-label and aria-describedby, or even the title attribute. Care must be taken when using aria-label however, because it will set the accessible Name property of the object and may obscure or even suppress any other labelling mechanism present within the active element, which may cause unexpected accessibility issues to occur. In contrast, aria-describedby or the title attribute will set the accessible Description property of the element, and will act as supplementary information when announced by ATs such as screen readers, making this a much safer option in most cases.

"I was thinking of using an aria grid, and dynamically updating the attributes when an element moved, but in a grid, items generally don't move."

Technically it is possible to implement an ARIA grid that supports movable cells or even rows, but the intuitiveness of such a construct is extremely difficult to convey without comprehensive help documentation or the training of specific users. There is no specific paradigm to cover this scenario, because there are too many possible variations. E.G a key combination can be used to move cells, or an attached menu, or even an embedded active element within the cell if more than one active element is present within it. Another issue you will encounter as your implementation becomes more complex, is that assistive technology support will likely decrease as your widget complexity increases, thus narrowing the number of users who will be able to intuitively use your widget accessibly.

"is this concept something that can even be solved with aria?"

First you need to start with a working widget that is already accessible from the keyboard, then ARIA can be added to enhance the accessibility of the widget using specific role and supporting attributes as needed. Going at it from the other direction where attempting to solve any problem with ARIA will never work quite as expected otherwise.

There are various online resources and tutorials that can help, even if not specifically with instructions to solve this one issue, but rather, to provide guidance about the accessible use of roles and supporting attributes and what to expect when these are applied. One such is available here, specifically sections 3.2, 3.3, and 3.4.
http://whatsock.com/training/#hd21<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwhatsock.com%2Ftraining%2F%23hd21&data=02%7C01%7Cv-shgubb%40microsoft.com%7C327592643a9246d5927c08d649f83cf3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636777727859445776&sdata=1uhEe8TpKo3AAqW%2BWDFgrEzUhBdJEyKoOIuMaH3Izo0%3D&reserved=0>

In many cases, simple underlying constructs can be used to provide accessibility support for complex UIs. For example, at times it is more advantageous to use a complex data table without ARIA to provide support by adding keyboard support to natively focusable active elements within the structure of associated cells, such as to native links, buttons, checkboxes, and radio buttons. Even if these natively focusable elements are not visibly displayed, the addition of classes on parent cells or rows can simulate the behavior of focused regions without impairing the native accessibility of these elements for assistive technology users. The same technique can be used to provide triggering elements to activate move actions or to provide dropdown menus that do the same for multiple drop targets.

So, in short, ARIA can be used to enhance accessibility for widgets that are already programmed to be keyboard accessible, but ARIA alone cannot solve any of these issues by itself. Hopefully this helps a bit.


*** End of thread response. ***

Regarding the general statement for the APG, I've taken a stab at this below.

It is important to note that the intended purpose of the Authoring Practices Guide, is to provide general design patterns for common widget types that utilize ARIA to enhance their functionality in accordance with the ARIA specification. In many cases, these code examples are deliberately simplistic to allow for easy modification and enhancement by developers, and to better illustrate important concepts within the coding process where ARIA is involved. The Authoring Practices Guide is not meant to represent all possible usages of ARIA, nor to cover all possible variations of specific widget types, but rather, to establish common usage patterns that demonstrate where and how specific ARIA roles and attributes should be used within the confines of a specific design pattern and usage paradigm. Additionally, the Authoring Practices Guide intentionally does not represent ARIA widgets that are universally supported by assistive technologies, but rather, is meant to provide a functional archive of common widget types that should be used by assistive technology providers to test against to ensure future conformance. For this reason, comprehensive testing with assistive technologies should always be performed when implementing any ARIA design pattern within production environments for public usage, to ensure that the design pattern being implemented is sufficiently supported to ensure accessibility.


Bryan Garaventa
Principle Accessibility Architect
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com<mailto:Bryan.Garaventa@LevelAccess.com>
415.624.2709 (o)
www.LevelAccess.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.LevelAccess.com&data=02%7C01%7Cv-shgubb%40microsoft.com%7C327592643a9246d5927c08d649f83cf3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636777727859445776&sdata=DtsIxWZ%2B63WwSCSPNig9Mw0p7RuAZBQJmTio9ys4O00%3D&reserved=0>

From: Ann Abbott <annabbott@gmail.com<mailto:annabbott@gmail.com>>
Sent: Monday, November 12, 2018 10:50 AM
To: Matt King <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>>
Cc: public-aria-practices@w3.org<mailto:public-aria-practices@w3.org>
Subject: Minutes for Monday, 12 November 2018 ARIA Authoring Practices Task Force

Minutes: https://www.w3.org/2018/11/12-aria-apg-minutes.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2018%2F11%2F12-aria-apg-minutes.html&data=02%7C01%7Cv-shgubb%40microsoft.com%7C327592643a9246d5927c08d649f83cf3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636777727859455785&sdata=NTlRGGyrR%2BS03mG6BhlPUV2om88B%2F0wK%2FSnfFIAKStI%3D&reserved=0>

Kind Regards,
Ann
annabbott@gmail.com<mailto:annabbott@gmail.com>
512-451-8267

On Mon, Nov 12, 2018 at 11:16 AM Matt King <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>> wrote:
Monday, 12 November 2018  ARIA Authoring Practices Task Force

Time: 10:00 AM US Pacific, 1:00 PM US Eastern
duration: 60 minutes
IRC server: irc.w3.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Firc.w3.org&data=02%7C01%7Cv-shgubb%40microsoft.com%7C327592643a9246d5927c08d649f83cf3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636777727859465797&sdata=vCd2sG7TjTZrcgTRlpz0RfZ98CI0bUVVMW8syjXtCfI%3D&reserved=0>, port: 6665, channel: #aria-apg
Agenda: https://github.com/w3c/aria-practices/wiki/November-12%2C-2018-Meeting<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Faria-practices%2Fwiki%2FNovember-12%252C-2018-Meeting&data=02%7C01%7Cv-shgubb%40microsoft.com%7C327592643a9246d5927c08d649f83cf3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636777727859475810&sdata=eBnpONvPzLvYBBFEIjGO%2BuWjkZHtcbVzHBEkOey8lfY%3D&reserved=0>
Topics:
* Issue triage
* Image carousel example
* Future meetings and other business

-------------------------------------------------------
To join the WebEx audio conference, you may call in via phone or join the online meeting and request a call back to any number.
US toll call-in: +1-617-324-0000
Access code (meeting number): 640 859 469
Mobile Auto Dial:+1-617-324-0000,,,640859469#

To join the online meeting:
1. Go to https://mit.webex.com/mit/j.php?MTID=ma880be53415dc3d751387cd2fcc47cb7<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmit.webex.com%2Fmit%2Fj.php%3FMTID%3Dma880be53415dc3d751387cd2fcc47cb7&data=02%7C01%7Cv-shgubb%40microsoft.com%7C327592643a9246d5927c08d649f83cf3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636777727859475810&sdata=J8rVYEDctfGZIBJ%2FErppyw%2BMg8fhMzV0E11vR7s8XEw%3D&reserved=0>
2. Enter your name and email address.
3. Enter the meeting password. You may ask for it on the IRC channel if you do not know it.
4. Click "Join".

WebEx support:
1. Go to https://mit.webex.com/mit/mc<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmit.webex.com%2Fmit%2Fmc&data=02%7C01%7Cv-shgubb%40microsoft.com%7C327592643a9246d5927c08d649f83cf3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636777727859485814&sdata=10%2B4hzkwmGGkvOmcuvV0TPQEHKm46OcssuCgGYzTWE0%3D&reserved=0>
2. From the left navigation bar, choose "Support".