Re: M11 Speech Input

>>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.

I don't think we can assume that is the meaning given that there is nothing
in the sentence that says "use a visible label" and there is an explicit
example given with no visible label...

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 2:01 PM, <alands289@gmail.com> wrote:

> 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 <david100@sympatico.ca>
> *Sent: *Tuesday, November 15, 2016 1:40 PM
> *To: *alands289@gmail.com
> *Cc: *Kim Patch <kim@redstartsystems.com>; Kathy Wahlbin
> <kathy@interactiveaccessibility.com>; Gregg Vanderheiden RTF
> <gregg@raisingthefloor.org>; Kathy Wahlbin <kathyw@ia11y.com>;
> 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
>
>
>
> *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: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 <kim@redstartsystems.com>
> *Sent: *Tuesday, November 15, 2016 12:32 PM
> *To: *David MacDonald <david100@sympatico.ca>; Kathy Wahlbin
> <kathy@interactiveaccessibility.com>
> *Cc: *Gregg Vanderheiden RTF <gregg@raisingthefloor.org>; Kathy Wahlbin
> <kathyw@ia11y.com>; 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
>
>
>
> *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
>
>
>
> *  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: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
> ___________________________________________________
>
>
>
>
>
>
>