Re: M11 Speech Input

Notes are normative although some have said they aren't... So, I agree
"presented to all users" in the note does show the intent that there is an
identifying feature about the interactive component that can be perceived
for all users, and presumably that would be a visual indication for those
without AT. Theoretically, there may be ways to  "present" the component
"to the user" without either an icon or a text label, but that's getting
pretty spacey and speculative.

Luckily, I can't remember coming across any examples of this ...

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 7:52 PM, Jonathan Avila <jon.avila@ssbbartgroup.com>
wrote:

> David, from a SC 3.3.2 perspective the definition of label is below with
> the addition of the note that you omitted.
>
> *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>
>
> *Note 1: *A label is presented to all users whereas the name
> <http://www.w3.org/TR/2008/REC-WCAG20-20081211/#namedef> may be hidden
> and only exposed by assistive technology. In many (but not all) cases the
> name and the label are the same.
>
> *Note 2: *The term label is not limited to the label element in HTML.
>
>
>
> Jonathan
>
>
>
> Jonathan Avila
>
> Chief Accessibility Officer
>
> SSB BART Group
>
> jon.avila@ssbbartgroup.com
>
> 703.637.8957 (Office)
>
>
>
> Visit us online: Website <http://www.ssbbartgroup.com/> | Twitter
> <https://twitter.com/SSBBARTGroup> | Facebook
> <https://www.facebook.com/ssbbartgroup> | Linkedin
> <https://www.linkedin.com/company/355266?trk=tyah> | Blog
> <http://www.ssbbartgroup.com/blog/>
>
> Join SSB at Accessing Higher Ground This Month!
> <http://www.ssbbartgroup.com/blog/join-ssb-accessing-higher-ground-month/>
>
>
>
> The information contained in this transmission may be attorney privileged
> and/or confidential information intended for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any use, dissemination,
> distribution or copying of this communication is strictly prohibited.
>
>
>
> *From:* David MacDonald [mailto:david100@sympatico.ca]
> *Sent:* Tuesday, November 15, 2016 6:05 PM
> *To:* Jonathan Avila
> *Cc:* public-mobile-a11y-tf@w3.org; Gregg Vanderheiden RTF
>
> *Subject:* Re: M11 Speech Input
>
>
>
> 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*
>
>
>
>
>
>
>