Re: M11 Speech Input

Yes, agree...

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 Wed, Nov 16, 2016 at 1:54 PM, Gregg Vanderheiden RTF <
gregg@raisingthefloor.org> wrote:

> +1
>
>
> *gregg*
>
> On Nov 16, 2016, at 1:48 PM, Michael Pluke <Mike.Pluke@castle-consult.com>
> wrote:
>
> As the meaning of terms in the glossary affect the meaning of normative
> statements (e.g. success criteria) that use those terms, I can see that it
> makes total sense to describe the glossary as “normative”.
>
> However, I still think that you are wise in not putting anything into
> notes that is “indispensable” as people familiar with standards from other
> bodies will not expect to see normative statements in notes. Even if this
> is allowable by W3C’s rules, normative statements in notes are likely to be
> a source of great confusion for people trying to understand the true scope
> of a success criterion.
>
> Best regards
>
> Mike
>
> *From:* David MacDonald [mailto:david100@sympatico.ca
> <david100@sympatico.ca>]
> *Sent:* 16 November 2016 14:04
> *To:* Michael Pluke <Mike.Pluke@castle-consult.com>
> *Cc:* Jonathan Avila <jon.avila@ssbbartgroup.com>;
> public-mobile-a11y-tf@w3.org; Gregg Vanderheiden RTF <
> gregg@raisingthefloor.org>
> *Subject:* Re: M11 Speech Input
>
> We can determine the Normative status of parts of the WCAG by a sentence
> after each heading for sections in WCAG that are normative.
>
> The glossary is Normative as indicated in the first sentence after the
> heading
>
> http://www.w3.org/TR/WCAG20/#glossary
>
> Many SCs rely on a very specific meaning of a word and that needs to be
> defined in a normative way so it doesn't change over the life of the WCAG.
>
> The notes attached to SCs and are under headings that say "Normative"
>
> I don't see anything that says they are exempt unless there is a global
> statement from the W3C that I don't know of. Perhaps they "shouldn't be"
> but I think they are.
>
> Having said that... we didn't put anything notes that was "indispensable"
> simply clarifying etc...
>
> 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 Wed, Nov 16, 2016 at 5:14 AM, Michael Pluke <
> Mike.Pluke@castle-consult.com> wrote:
>
> I am not sufficiently familiar with W3C conventions, but I’m a little
> surprised to hear that notes are normative. In ISO and the European
> Standards Organisations like ETSI, notes *cannot* contain normative
> elements. Specifically ETSI says:
>
> “They shall not contain any information considered indispensable for the
> use of the deliverable.”
>
> and anything that is normative is indispensable to the (proper) use of the
> standard.
>
> But in this instance I am even more puzzled. We are talking here about a
> *definition*. Surely the concept of normative isn’t relevant to a
> definition. A definition is just an explanation of what is meant by a word.
>
> In this case, Note 1 is written as a statement of fact (using the words
> “is presented”). It is not telling anyone that labels *must* be
> presented. Only a success criterion can attempt to enforce that.
>
> Best regards
>
> Mike
>
> *From:* David MacDonald [mailto:david100@sympatico.ca]
> *Sent:* 16 November 2016 01:23
> *To:* Jonathan Avila <jon.avila@ssbbartgroup.com>
> *Cc:* public-mobile-a11y-tf@w3.org; Gregg Vanderheiden RTF <
> gregg@raisingthefloor.org>
>
> *Subject:* 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*
>
>
>