Re: M11 Speech Input

Perhaps in 2.1 we can amend that to

label

text <http://www.w3.org/TR/2008/REC-WCAG20-20081211/#textdef> or other
<add>visible</add> component with a text alternative
<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#text-altdef> that is
presented to a user to identify a component within Web content
<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#contentdef>


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 6:05 PM, David MacDonald <david100@sympatico.ca>
wrote:

> I'm not sure I agree... I want to... The definition of a label doesn't say
> it has to be visible, and we have the example with a title attribute in F65
> and example 2 has a three part phone number ... and two of the inputs don't
> have visible labels to correspond to the title...
>
> label
>
> text <http://www.w3.org/TR/2008/REC-WCAG20-20081211/#textdef> or other
> component with a text alternative
> <http://www.w3.org/TR/2008/REC-WCAG20-20081211/#text-altdef> that is
> presented to a user to identify a component within Web content
> <http://www.w3.org/TR/2008/REC-WCAG20-20081211/#contentdef>
>
>
>
>
> 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:46 PM, Jonathan Avila <
> jon.avila@ssbbartgroup.com> wrote:
>
>> > 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>
>> 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
>>
>>
>>
>> *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 1:40 PM, Gregg Vanderheiden RTF <
>> 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> 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
>>> <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*
>>>
>>>
>>>
>>
>