Re: M11 Speech Input

Visual labels can make the view more cluttered, requiring a little more cognitive effort. Visual labels can decrease screen space for content and increase the need to scroll, which can be more difficult for people with mobility issues.

Cheers,
Kim

Kim Patch
www.scriven.com/kimpatch.html


> On Nov 15, 2016, at 1:26 PM, <alands289@gmail.com> <alands289@gmail.com> wrote:
> 
> Kim,
>  
> Can you expound on your statement that “visible labels all the time can be bad”?
>  
> Are not labels required for input fields per 3.3.2? And placeholder text should not be a substitute for a visible label.
> Finally, they are actually required for graphic symbols by 1.3.3’s F26 but few people flag them as needing them.
> This F26 is a little known failure, but it is there.
>  
> Alan
> 
> Sent from Mail for Windows 10
>  
> From: Kim Patch
> Sent: Tuesday, November 15, 2016 12:32 PM
> To: David MacDonald; Kathy Wahlbin
> Cc: Gregg Vanderheiden RTF; Kathy Wahlbin; public-mobile-a11y-tf@w3.org
> Subject: Re: M11 Speech Input
>  
> How about
> 
> "The user has the option to show persistent, visible labels on all active elements." 
> 
> I think it's important that labels are an option for the user because visible labels all the time can be bad for other users.
> 
> Cheers,
> Kim
> 
> On 11/15/2016 10:37 AM, David MacDonald wrote:
> 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
>  
> CanAdapt Solutions Inc.
> Tel:  613.235.4902
> LinkedIn 
> twitter.com/davidmacd
> GitHub
> 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
>  
> 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
>  
> 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
>  
> 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
>  
>  
>  
> -- 
> ___________________________________________________ 
> 
> Kimberly Patch
> President
> Redstart Systems
> (617) 325-3966
> kim@redstartsystems.com
> 
> www.redstartsystems.com
> - making speech fly
> 
> Blog: Patch on Speech
> +Kim Patch
> @RedstartSystems 
> www.linkedin.com/in/kimpatch
> ___________________________________________________
>