Re: M11 Speech Input

> I don't think we have a requirement now for a visible label. I wish we did...

SC 3.3.2 requires a visual label but not require it to be text.     It could be an icon.

Jon

Sent from my iPhone

On Nov 15, 2016, at 4:17 PM, David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>> wrote:

I don't think we have a requirement now for a visible label. I wish we did...

For instance we allow the "title" attribute on inputs to serve as the label... (which I've never been in favour of)

https://www.w3.org/TR/WCAG20-TECHS/H65.html


Cheers,
David MacDonald



CanAdapt Solutions Inc.

Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd<http://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 1:40 PM, Gregg Vanderheiden RTF <gregg@raisingthefloor.org<mailto:gregg@raisingthefloor.org>> wrote:
Isn’t that already covered by the SC requiring  the label to be “programatically determinable”.

1.3.1 requires all information presented visually   to be PD   (and the label is presented visually).

the intent of 1.3.1 was that any information not already PD because of 1.1.1  - be PD.

gregg

On Nov 15, 2016, at 5:29 AM, Kathy Wahlbin <kathy@interactiveaccessibility.com<mailto: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<tel:%28978%29%C2%A0443-0798>  F (978) 560-1251<tel:%28978%29%C2%A0560-1251>  C (978) 760-0682<tel:%28978%29%C2%A0760-0682>
E kathyw@ia11y.com<mailto: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<mailto:kathyw@ia11y.com>>
Cc: public-mobile-a11y-tf@w3.org<mailto: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<mailto:greggvan@umd.edu>



On Nov 14, 2016, at 10:57 PM, Kathy Wahlbin <kathyw@ia11y.com<mailto: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<tel:%28978%29%C2%A0443-0798>  F (978) 560-1251<tel:%28978%29%C2%A0560-1251>  C (978) 760-0682<tel:%28978%29%C2%A0760-0682>
E kathyw@ia11y.com<mailto: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