Re: Proposed APG usage statement and GitHub response

+1

Kind Regards,
Ann
annabbott@gmail.com
512-451-8267


On Wed, Nov 14, 2018 at 5:41 PM James Nurthen <nurthen@adobe.com> wrote:

> 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
>
>
>
>
>
>
>
> *From: *"Siri Gubba (Artech Consulting LLC)" <v-shgubb@microsoft.com>
> *Date: *Wednesday, November 14, 2018 at 6:48 AM
> *To: *"Ku, JaEun Jemma" <jku@illinois.edu>, Ann Abbott <
> annabbott@gmail.com>
> *Cc: *"McCarthy, Mark C" <mcmccar2@uillinois.edu>, "
> public-aria-practices@w3.org" <public-aria-practices@w3.org>
> *Subject: *RE: Proposed APG usage statement and GitHub response
> *Resent-From: *<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>
> *Sent:* Wednesday, November 14, 2018 12:13 AM
> *To:* 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
>
>
>
> 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> 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
> 512-451-8267
>
>
>
>
>
> On Tue, Nov 13, 2018 at 2:19 PM McCarthy, Mark C <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 <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>
> *Sent:* Tuesday, November 13, 2018 12:31 PM
> *To:* 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
>
> 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>
> *Sent:* Monday, November 12, 2018 10:50 AM
> *To:* Matt King <a11ythinker@gmail.com>
> *Cc:* 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
> 512-451-8267
>
>
>
> On Mon, Nov 12, 2018 at 11:16 AM Matt King <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".
>
>