RE: M11 Speech Input

David,

Good point. I’ve taken the clause “provide an alternative using features of the technology or use a different mechanism that can be marked with an alternative to represent the graphical symbol.” to mean a visible label. Low vision users need that while blind users would require some announced alternative. Eight years ago we did not have the proliferation of icons that are often impossible to know what they stand for.

Thanks.

Alan

Sent from Mail for Windows 10

From: David MacDonald
Sent: Tuesday, November 15, 2016 1:40 PM
To: alands289@gmail.com
Cc: Kim Patch; Kathy Wahlbin; Gregg Vanderheiden RTF; Kathy Wahlbin; public-mobile-a11y-tf@w3.org
Subject: Re: M11 Speech Input

I don't think F26 requires a visual label... it just requires alternate text the graphic. It says in the description.

"For example, an image with a text alternative can be used instead of the glyph."


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 1:26 PM, <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
___________________________________________________