- From: David MacDonald <david100@sympatico.ca>
- Date: Tue, 15 Nov 2016 10:37:40 -0500
- To: Kathy Wahlbin <kathy@interactiveaccessibility.com>
- Cc: Gregg Vanderheiden RTF <gregg@raisingthefloor.org>, Kathy Wahlbin <kathyw@ia11y.com>, "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>
- Message-ID: <CAAdDpDYRaKORn8uhWmNa9awjxtRxOe6j8WiUO_mqRQ_8C63k3Q@mail.gmail.com>
Agree that this is an improvement and can act as a placeholder to get it into the WCAG 2.1 SC consideration process Dec 1 deadline. Perhaps after later it can be cleaned up to articulate the characteristics that the content has... Perhaps something like. "All buttons have visible labels." or a combination of few things that make up the bulk of the problem that "don't interfere with dictation" tries to solve, etc... 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, Nov 15, 2016 at 5:29 AM, Kathy Wahlbin < kathy@interactiveaccessibility.com> wrote: > Hi Greg – > > > > We will be discussing this on the call on Thursday but other than keyboard > access (which is already covered under 2.1.1), a user cannot directly > access a control using speech directly is when the name of a control does > not include the visual name (e.g. a button is visually labeled as continue > but in the code is it submit). This can be controlled in the content and > would be a technique of this proposed SC. > > > > Kathy > > CEO & Founder > > Interactive Accessibility > > > > *T* (978) 443-0798 *F* (978) 560-1251 *C* (978) 760-0682 > *E* kathyw@ia11y.com > > www.InteractiveAccessibility.com > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.interactiveaccessibility.com_&d=CwMGaQ&c=jxhwBfk-KSV6FFIot0PGng&r=UK__SX18Mp9Fb6tIJfzgjkhM1qTux9WksegD3zR-Bss&m=Kyx2xjSikKdohzK4YYjpf6lkpNeSYzbcW2-3BWkmRfM&s=QvEa6SOOfiPYi3edgtQBne9UjZFUHulJz3xqkGwAu7o&e=> > > > > NOTICE: This communication may contain privileged or other confidential > information. If you are not the intended recipient, please reply to the > sender indicating that fact and delete the copy you received. Any > disclosure, copying, distribution or action taken or omitted to be taken by > an unintended recipient in reliance on this message is prohibited and may > be unlawful. > > > > *From:* Gregg Vanderheiden RTF [mailto:gregg@raisingthefloor.org] > *Sent:* Tuesday, November 15, 2016 12:47 AM > *To:* Kathy Wahlbin <kathyw@ia11y.com> > *Cc:* public-mobile-a11y-tf@w3.org > *Subject:* Re: M11 Speech Input > > > > agree with removal of keyboard — it takes the focus away from the real > goal of the SC and it redundant with 2.1.1 > > > > question: > > - are you talking about speech input to the content? or to the > device? > - If you are talking about speech input to the device — I don’t see > how the content could possibly do this. The content would have no idea > that anyone was using speech input to the mobile device. such and SC > would mean that content could never play music or talk to the user - > because both could interfere with speech input. > - Not interfering with speech input is something the DEVICE needs to > do. for example — when you select to speak into the device - the device > can mute the output from the content. But the content itself has no idea > when this is happening. > > > > What do you propose as as success criteria (that content can do) to meet > this requirement (other than never making andy sound or speech output > itself) ? > > > > > > Gregg C Vanderheiden > > greggvan@umd.edu > > > > > > > > On Nov 14, 2016, at 10:57 PM, Kathy Wahlbin <kathyw@ia11y.com> wrote: > > > > Hi – > > > > In looking over the proposed SCs, I think we need to update the text of > the SC for Speech Input. Keyboard access is already required under 2.1.1 > so we do not need to require it here. > > > > https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_Speech_Input > > > > *Current SC Text:* > > > > All functionality of the content (including touch and gesture) is operable > through the keyboard, and does not obstruct a user’s ability to access the > keyboard commands through speech input. > > > > *Recommended Update to SC Text:* > > > > All functionality of the content does not obstruct a user’s ability to > access the commands through speech input. > > > > Thoughts? > > > > Kathy > > CEO & Founder > > Interactive Accessibility > > > > *T* (978) 443-0798 *F* (978) 560-1251 *C* (978) 760-0682 > *E* kathyw@ia11y.com > > www.InteractiveAccessibility.com > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.interactiveaccessibility.com_&d=CwMGaQ&c=jxhwBfk-KSV6FFIot0PGng&r=UK__SX18Mp9Fb6tIJfzgjkhM1qTux9WksegD3zR-Bss&m=Kyx2xjSikKdohzK4YYjpf6lkpNeSYzbcW2-3BWkmRfM&s=QvEa6SOOfiPYi3edgtQBne9UjZFUHulJz3xqkGwAu7o&e=> > > > > NOTICE: This communication may contain privileged or other confidential > information. If you are not the intended recipient, please reply to the > sender indicating that fact and delete the copy you received. Any > disclosure, copying, distribution or action taken or omitted to be taken by > an unintended recipient in reliance on this message is prohibited and may > be unlawful. > > > > > > > *gregg* > > >
Received on Tuesday, 15 November 2016 15:38:15 UTC