Re: Proposed APG usage statement and GitHub response

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 <http://pronoun.is/he?or=they>*
>
> *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
>
>
>
> 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
>
>
>
> *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
>
>
> 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, port: 6665, channel: #aria-apg
> Agenda:
> https://github.com/w3c/aria-practices/wiki/November-12%2C-2018-Meeting
> 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
> 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
> 2. From the left navigation bar, choose "Support".
>
>