Re: 1.4.2 audio control, do we want to require the stop mechanism to be more discoverable?

It appears there is no key combination in Chrome to mute a tab even though
the functionality is available to mouse users.

There is a 3rd party plugin that does this.

https://chrome.google.com/webstore/detail/mute-tab-shortcuts/opcjanmpjbdbdpnjfjbboacibokblbhl

I filed a bug with Chrome
https://bugs.chromium.org/p/chromium/issues/detail?id=627771

This should definitely be available to keyboard users by default as it is
on FireFox.


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 12, 2016 at 2:23 PM, Katie Haritos-Shea GMAIL <ryladog@gmail.com
> wrote:

> +1 to device independent, easily findable and clearly visible
>
>
>
> ​​​​​
>
>
>
>
>
>
>
> ** katie **
>
>
>
> *Katie Haritos-Shea*
> *Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)*
>
>
>
> *Cell: 703-371-5545 <703-371-5545> **|* *ryladog@gmail.com*
> <ryladog@gmail.com> *|* *Oakton, VA **|* *LinkedIn Profile*
> <http://www.linkedin.com/in/katieharitosshea/> *|* *Office: 703-371-5545
> <703-371-5545> **|* *@ryladog* <https://twitter.com/Ryladog>
>
>
>
> *From:* Jonathan Avila [mailto:jon.avila@ssbbartgroup.com]
> *Sent:* Tuesday, July 12, 2016 1:58 PM
> *To:* WCAG <w3c-wai-gl@w3.org>
>
> *Subject:* RE: 1.4.2 audio control, do we want to require the stop
> mechanism to be more discoverable?
>
>
>
> Ø  *If we had IndieUI Events, the user could rely on a familiar keyboard
> or other mechanism to stop/pause playback. I also agree that advances of
> screen readers*
>
>
>
> It would be awesome if we could have page level actions that were
> available to the user without knowing specific keystrokes or reaching
> certain links. The page would define an array of actions and descriptions
> and then user agents or assistive technology could present these to the
> user in the method of their choosing such as menu, rotor, etc.  The same
> thing could go for individual controls as well allowing device independent
> access to actions.
>
>
>
> Jonathan
>
>
>
> Jonathan Avila
>
> Chief Accessibility Officer
> SSB BART Group
> jon.avila@ssbbartgroup.com
>
> 703.637.8957 (Office)
> Visit us online: Website <http://www.ssbbartgroup.com/> | Twitter
> <https://twitter.com/SSBBARTGroup> | Facebook
> <https://www.facebook.com/ssbbartgroup> | Linkedin
> <https://www.linkedin.com/company/355266?trk=tyah> | Blog
> <http://www.ssbbartgroup.com/blog/>
>
> Check out our Digital Accessibility Webinars!
> <http://www.ssbbartgroup.com/webinars/>
>
>
>
> *From:* White, Jason J [mailto:jjwhite@ets.org <jjwhite@ets.org>]
> *Sent:* Monday, July 11, 2016 4:35 PM
> *To:* David MacDonald; WCAG
> *Subject:* RE: 1.4.2 audio control, do we want to require the stop
> mechanism to be more discoverable?
>
>
>
>
>
>
>
> *From:* David MacDonald [mailto:david100@sympatico.ca
> <david100@sympatico.ca>]
> *Sent:* Monday, July 11, 2016 3:56 PM
>
> Do we want to look at 1.4.2 for WCAG 2.1 to ensure the mechanism to stop
> auto play of music is easy to find and get to... currently the mechanism
> can be anywhere...
>
>
>
> or should we look at the advances in Screen Readers (VO etc...) that force
> other system sounds to drop in volume when AT is running, as a positive
> step towards overcoming the problem in AT and user agents and not make any
> changes in 2.1?
>
> *[Jason] Requiring the control to be easy to locate would entail
> modification of the presentation of the Web page that goes beyond what we
> allow in Level A success criteria. However, we could add a requirement at
> level AA.*
>
> *If we had IndieUI Events, the user could rely on a familiar keyboard or
> other mechanism to stop/pause playback. I also agree that advances of
> screen readers make that particular use case less necessary than it once
> was.*
>
> Perhaps there ought to be a “controls” ARIA landmark role in ARIA 2.0, in
> which case it (or a similar mechanism) could be required at Level A.
>
> Suggestions?
>
>
>
>
> ------------------------------
>
> This e-mail and any files transmitted with it may contain privileged or
> confidential information. It is solely for use by the individual for whom
> it is intended, even if addressed incorrectly. If you received this e-mail
> in error, please notify the sender; do not disclose, copy, distribute, or
> take any action in reliance on the contents of this information; and delete
> it from your system. Any other use of this e-mail is prohibited.
>
>
>
> Thank you for your compliance.
> ------------------------------
>