E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 10 (In chronological order)

From: Robert Fentress
Date: Sun, Feb 07 2016 2:23PM
Subject: Activating controls with hidden accessible names using speech recognition
No previous message | Next message →

Hi, all.

I'm curious about the accessibility for speech recognition software
users of controls whose accessible name is not visible. One example
is graphical buttons or links. Using Dragon, one could say "click
button" and be shown selection boxes for all buttons on the screen,
allowing you to choose the one you wanted. However, that seems like
an added burden when, if the name was visible, you could simply say
its name to click it. I only have access to Dragon 12.5, so I don't
know if they've come up with better solutions for situations like this
in later versions, but I'm wondering if having an option to display
hidden labels would assist users of this assistive technology.

Using graphical controls can be a way of making things less cluttered
and easier to grasp perhaps, but it seems to make things more
difficult than it should be for those using voice control.

Also, I'm wondering if it is recommended practice to try to avoid
having controls whose accessible name doesn't match what appears
visually to be its name. For instance, visibly, it might say "read
more", but its hidden name might be set to "read full entry for topic
1" using aria-label to disambiguate things for screen reader users.
In this instance, I could see a Dragon user saying "click read more"
and being confused when nothing happens.

Perhaps these are just examples of trade-offs where you need to use
your best judgement, but I wonder if there are recommendations or best
practices for things like this. You wouldn't ding someone for not
having visible labels or having visible labels that are different than
hidden labels, would you?

Thanks.

-Rob

From: Jonathan Avila
Date: Mon, Feb 08 2016 7:38AM
Subject: Re: Activating controls with hidden accessible names usingspeech recognition
← Previous message | Next message →

Robert, these are important considerations that I discuss in a blog article on the topic titled Considerations for Testing with Speech Recognition Software such as Dragon Naturally Speaking that I authored in 2014 http://www.ssbbartgroup.com/blog/considerations-testing-speech-recognition-software-dragon-naturally-speaking/

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =
703.637.8957 (o)
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter


-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Robert Fentress
Sent: Sunday, February 07, 2016 4:24 PM
To: WebAIM Discussion List
Subject: [WebAIM] Activating controls with hidden accessible names using speech recognition

Hi, all.

I'm curious about the accessibility for speech recognition software users of controls whose accessible name is not visible. One example is graphical buttons or links. Using Dragon, one could say "click button" and be shown selection boxes for all buttons on the screen, allowing you to choose the one you wanted. However, that seems like an added burden when, if the name was visible, you could simply say its name to click it. I only have access to Dragon 12.5, so I don't know if they've come up with better solutions for situations like this in later versions, but I'm wondering if having an option to display hidden labels would assist users of this assistive technology.

Using graphical controls can be a way of making things less cluttered and easier to grasp perhaps, but it seems to make things more difficult than it should be for those using voice control.

Also, I'm wondering if it is recommended practice to try to avoid having controls whose accessible name doesn't match what appears visually to be its name. For instance, visibly, it might say "read more", but its hidden name might be set to "read full entry for topic 1" using aria-label to disambiguate things for screen reader users.
In this instance, I could see a Dragon user saying "click read more"
and being confused when nothing happens.

Perhaps these are just examples of trade-offs where you need to use your best judgement, but I wonder if there are recommendations or best practices for things like this. You wouldn't ding someone for not having visible labels or having visible labels that are different than hidden labels, would you?

Thanks.

-Rob

From: deborah.kaplan@suberic.net
Date: Mon, Feb 08 2016 10:24PM
Subject: Re: Activating controls with hidden accessible names using speech recognition
← Previous message | Next message →

Robert Fentress wrote:

> I'm curious about the accessibility for speech recognition software users of controls whose accessible name is not visible.

Robert,

Assuming the accessible name is properly associated with ARIA, NaturallySpeaking allows the user to dictate the accessible name. However, the user needs to know what the accessible name *is*. With very few exceptions (a magnifying glass, a shopping cart, a gear, or a question mark) it's almost impossible for the user to even guess.

Now, of course, best practice is always to label icons (<https://www.nngroup.com/articles/icon-usability/>) because able-bodied users also find sites difficult to navigate without text labels. But current design trends sadly have little to do with evidence-based usability. So in order to make the icons easily usable by Dragon users, the site needs to find some way to expose textual labels (without relying on hover based effects such as flyout menus or title attributes).


> Also, I'm wondering if it is recommended practice to try to avoid having controls whose accessible name doesn't match what appears visually to be its name. For instance, visibly, it might say "read more", but its hidden name might be set to "read full entry for topic 1" using aria-label to disambiguate things for screen reader users.

I'm not positive, but I believe Dragon does partial matches in that case. However, if the text is "read more" and the aria-label is "find more information about Foo", that would be a terrible plan.

> Perhaps these are just examples of trade-offs where you need to use your best judgement, but I wonder if there are recommendations or best practices for things like this. You wouldn't ding someone for not having visible labels or having visible labels that are different than hidden labels, would you?

Well, I would, but that's because pretty much all user testing ever shows that users will navigate your site more effectively with a combination of icon + text label.

Deborah Kaplan

From: _mallory
Date: Tue, Feb 09 2016 1:41AM
Subject: Re: Activating controls with hidden accessible names using speech recognition
← Previous message | Next message →

I was discussing icons and icons+labels with my team. The Design group
really didn't want text next to icons. Lord knows why.

However I recently purchased my first smart phone, a Nokia. They have
icons+text, BUT as a user you can choose whether or not you gets just
icons (you have more free screen room) or also text, with a single control
per menu group.

Of course, that control itself has no text (lawlz), however all menu groups
have that same control icon and basically allows text to slide up next
to its icons.

I can see websites simply offering, as some applications do, a 1-button
option to show the text (or hide it, depending on the website's default),
allowing people like me who can't make heads or tails of icons (I often
hit F12 just to see if either a class name or another name or hidden
text is available to tell me what the thing will do) or people like speech
users be able to always have text available, while graphics people can
still show a pretty icon-only interface to CEOs and clients.

_mallory

On Tue, Feb 09, 2016 at 12:24:39AM -0500, = EMAIL ADDRESS REMOVED = wrote:
> Robert Fentress wrote:
>
> >I'm curious about the accessibility for speech recognition software users of controls whose accessible name is not visible.
>
> Robert,
>
> Assuming the accessible name is properly associated with ARIA, NaturallySpeaking allows the user to dictate the accessible name. However, the user needs to know what the accessible name *is*. With very few exceptions (a magnifying glass, a shopping cart, a gear, or a question mark) it's almost impossible for the user to even guess.
>
> Now, of course, best practice is always to label icons (<https://www.nngroup.com/articles/icon-usability/>) because able-bodied users also find sites difficult to navigate without text labels. But current design trends sadly have little to do with evidence-based usability. So in order to make the icons easily usable by Dragon users, the site needs to find some way to expose textual labels (without relying on hover based effects such as flyout menus or title attributes).
>
>
> >Also, I'm wondering if it is recommended practice to try to avoid having controls whose accessible name doesn't match what appears visually to be its name. For instance, visibly, it might say "read more", but its hidden name might be set to "read full entry for topic 1" using aria-label to disambiguate things for screen reader users.
>
> I'm not positive, but I believe Dragon does partial matches in that case. However, if the text is "read more" and the aria-label is "find more information about Foo", that would be a terrible plan.
>
> >Perhaps these are just examples of trade-offs where you need to use your best judgement, but I wonder if there are recommendations or best practices for things like this. You wouldn't ding someone for not having visible labels or having visible labels that are different than hidden labels, would you?
>
> Well, I would, but that's because pretty much all user testing ever shows that users will navigate your site more effectively with a combination of icon + text label.
>
> Deborah Kaplan
> > > >

From: Cliff Tyllick
Date: Tue, Feb 09 2016 8:41AM
Subject: Re: Activating controls with hidden accessible names using speech recognition
← Previous message | Next message →

Mallory said:

"…while graphics people can
still show a pretty icon-only interface to CEOs and clients."

You know what would really be great? A similar approach for the carrousel. [smile]

Cliff Tyllick
Accessibility Specialist
Texas Department of Assistive and Rehabilitative Services

Sent from my iPhone
Although its spellcheck often saves me, all goofs in sent messages are its fault.

> On Feb 9, 2016, at 2:41 AM, _mallory < = EMAIL ADDRESS REMOVED = > wrote:
>
> while graphics people can
> still show a pretty icon-only interface to CEOs and clients.

From: _mallory
Date: Tue, Feb 09 2016 8:44AM
Subject: Re: Activating controls with hidden accessible names using speech recognition
← Previous message | Next message →

Zomg and 9px light-grey text on white!

On Tue, Feb 09, 2016 at 09:41:56AM -0600, Cliff Tyllick wrote:
> Mallory said:
>
> "…while graphics people can
> still show a pretty icon-only interface to CEOs and clients."
>
> You know what would really be great? A similar approach for the carrousel. [smile]
>
> Cliff Tyllick
> Accessibility Specialist
> Texas Department of Assistive and Rehabilitative Services
>
> Sent from my iPhone
> Although its spellcheck often saves me, all goofs in sent messages are its fault.
>
> > On Feb 9, 2016, at 2:41 AM, _mallory < = EMAIL ADDRESS REMOVED = > wrote:
> >
> > while graphics people can
> > still show a pretty icon-only interface to CEOs and clients.
> > > >

From: Robert Fentress
Date: Wed, Feb 10 2016 7:15AM
Subject: Re: Activating controls with hidden accessible names using speech recognition
← Previous message | Next message →

All good points. However, I can hear the person whose site I'm
evaluating saying something like, "We'll, my application is very
complex and making these things into icons allows me to fit more
functionality into a limited space, thus making it so users do not
have to spend a lot of time rooting through separate pages to get to
the functionality they need. The icons are more easily recognizable
at a glance than text labels would be and thus reduce the cognitive
load, once you are familiar with what they mean."

I like the idea of having a way of enabling text labels if desired.
However, I have a hard time imagining how that could happen without a
major interface redesign at this point.

Oh well, I guess I just need to make them aware of the issues and
provide possible solutions. It's up to them figure out how (or if)
they can implement them given their resources.

There is also the question of at what point this becomes a user agent
responsibility. I mean, the information is there and I'd argue speech
control software should provide the option to make it available
visually. If every label must be visible to everyone all the time,
what is the point of things like aria-label and chained ids for
aria-labelledby?

On Mon, Feb 8, 2016 at 9:38 AM, Jonathan Avila
< = EMAIL ADDRESS REMOVED = > wrote:
> Robert, these are important considerations that I discuss in a blog article on the topic titled Considerations for Testing with Speech Recognition Software such as Dragon Naturally Speaking that I authored in 2014 http://www.ssbbartgroup.com/blog/considerations-testing-speech-recognition-software-dragon-naturally-speaking/
>
> Jonathan
>
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED =
> 703.637.8957 (o)
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Robert Fentress
> Sent: Sunday, February 07, 2016 4:24 PM
> To: WebAIM Discussion List
> Subject: [WebAIM] Activating controls with hidden accessible names using speech recognition
>
> Hi, all.
>
> I'm curious about the accessibility for speech recognition software users of controls whose accessible name is not visible. One example is graphical buttons or links. Using Dragon, one could say "click button" and be shown selection boxes for all buttons on the screen, allowing you to choose the one you wanted. However, that seems like an added burden when, if the name was visible, you could simply say its name to click it. I only have access to Dragon 12.5, so I don't know if they've come up with better solutions for situations like this in later versions, but I'm wondering if having an option to display hidden labels would assist users of this assistive technology.
>
> Using graphical controls can be a way of making things less cluttered and easier to grasp perhaps, but it seems to make things more difficult than it should be for those using voice control.
>
> Also, I'm wondering if it is recommended practice to try to avoid having controls whose accessible name doesn't match what appears visually to be its name. For instance, visibly, it might say "read more", but its hidden name might be set to "read full entry for topic 1" using aria-label to disambiguate things for screen reader users.
> In this instance, I could see a Dragon user saying "click read more"
> and being confused when nothing happens.
>
> Perhaps these are just examples of trade-offs where you need to use your best judgement, but I wonder if there are recommendations or best practices for things like this. You wouldn't ding someone for not having visible labels or having visible labels that are different than hidden labels, would you?
>
> Thanks.
>
> -Rob
> > > > > > > --
Robert Fentress
Senior Accessibility Solutions Designer
540.231.1255

Technology-enhanced Learning & Online Strategies
Assistive Technologies
1180 Torgersen Hall
620 Drillfield Drive (0434)
Blacksburg, Virginia 24061

From: _mallory
Date: Wed, Feb 10 2016 8:52AM
Subject: Re: Activating controls with hidden accessible names using speech recognition
← Previous message | Next message →

"The icons are more easily recognizable at a glance than text labels"

Actually I remember reading a study (or a reference to a study) showing
that in an application, what users really remember is *where* the icon
is, rather than what the icon looks like. Other things like the colour
and size were also more remembered.

I like the idea of the UA exposing these names to any user who asks.

_mallory

On Wed, Feb 10, 2016 at 09:15:23AM -0500, Robert Fentress wrote:
> All good points. However, I can hear the person whose site I'm
> evaluating saying something like, "We'll, my application is very
> complex and making these things into icons allows me to fit more
> functionality into a limited space, thus making it so users do not
> have to spend a lot of time rooting through separate pages to get to
> the functionality they need. The icons are more easily recognizable
> at a glance than text labels would be and thus reduce the cognitive
> load, once you are familiar with what they mean."
>
> I like the idea of having a way of enabling text labels if desired.
> However, I have a hard time imagining how that could happen without a
> major interface redesign at this point.
>
> Oh well, I guess I just need to make them aware of the issues and
> provide possible solutions. It's up to them figure out how (or if)
> they can implement them given their resources.
>
> There is also the question of at what point this becomes a user agent
> responsibility. I mean, the information is there and I'd argue speech
> control software should provide the option to make it available
> visually. If every label must be visible to everyone all the time,
> what is the point of things like aria-label and chained ids for
> aria-labelledby?
>

From: Cliff Tyllick
Date: Wed, Feb 10 2016 12:33PM
Subject: Re: Activating controls with hidden accessible names using speech recognition
← Previous message | Next message →

The classic case of recognizable icons is the so-called Hamburger icon for site navigation. Except that hardly anybody recognizes it as well as they think they do.

Even people who know what it represents tend not to use it without first stopping to think about it. Put one word beneath it—"Menu"—and everybody recognizes what it is and uses it without giving it a second thought when it's the thing they need. At least that's what I am told by usability professionals who test this design element again and again, one client at a time.

People will tell you that they recognize and use the unlabeled icon, but if you observe their behavior you will see that much of the time they don't.

The bottom line is to avoid creating text-free interfaces. Icons rarely are as recognizable and unambiguous as we think.

Put me solidly in the camp of liking the proposed approach. If the design is responsive, it shouldn't lead to that much trouble.

Cliff

Cliff Tyllick
Accessibility Specialist
Texas Department of Assistive and Rehabilitative Services

Sent from my iPhone
Although its spellcheck often saves me, all goofs in sent messages are its fault.

> On Feb 10, 2016, at 9:52 AM, _mallory < = EMAIL ADDRESS REMOVED = > wrote:
>
> "The icons are more easily recognizable at a glance than text labels"
>
> Actually I remember reading a study (or a reference to a study) showing
> that in an application, what users really remember is *where* the icon
> is, rather than what the icon looks like. Other things like the colour
> and size were also more remembered.
>
> I like the idea of the UA exposing these names to any user who asks.
>
> _mallory
>
>> On Wed, Feb 10, 2016 at 09:15:23AM -0500, Robert Fentress wrote:
>> All good points. However, I can hear the person whose site I'm
>> evaluating saying something like, "We'll, my application is very
>> complex and making these things into icons allows me to fit more
>> functionality into a limited space, thus making it so users do not
>> have to spend a lot of time rooting through separate pages to get to
>> the functionality they need. The icons are more easily recognizable
>> at a glance than text labels would be and thus reduce the cognitive
>> load, once you are familiar with what they mean."
>>
>> I like the idea of having a way of enabling text labels if desired.
>> However, I have a hard time imagining how that could happen without a
>> major interface redesign at this point.
>>
>> Oh well, I guess I just need to make them aware of the issues and
>> provide possible solutions. It's up to them figure out how (or if)
>> they can implement them given their resources.
>>
>> There is also the question of at what point this becomes a user agent
>> responsibility. I mean, the information is there and I'd argue speech
>> control software should provide the option to make it available
>> visually. If every label must be visible to everyone all the time,
>> what is the point of things like aria-label and chained ids for
>> aria-labelledby?
> > > >

From: _mallory
Date: Fri, Feb 12 2016 5:09AM
Subject: Re: Activating controls with hidden accessible names using speech recognition
← Previous message | No next message

I was talking more about applications with a lot of icons:
https://www.uie.com/brainsparks/2006/02/20/orbitz-cant-get-a-date/
It was more that people, if they used the application more than
once (most websites I go to with hamburgers, I only ever visit
once), they learn "I go over here to do x" rather than pay attention
to what the icon actually looks like. Muscle memory I guess.

I had to recently go add to our icons fonts via the icomoon "app."
Zomg. I am an easily frustrated person I'll admit, but little
compares to the frustration of trying to use that site without
someone else to tell you what all the buttons do and what order
you're expected to do stuff. I wrote instructions for future-me's,
with lines like "ignore the eyeball thing, and click on the stripy
bar thing to get a menu. The text that says 'X' refers to 'Y' not 'Z'
so choose that".

_mallory

On Wed, Feb 10, 2016 at 01:33:37PM -0600, Cliff Tyllick wrote:
> The classic case of recognizable icons is the so-called Hamburger icon for site navigation. Except that hardly anybody recognizes it as well as they think they do.
>
> Even people who know what it represents tend not to use it without first stopping to think about it. Put one word beneath it—"Menu"—and everybody recognizes what it is and uses it without giving it a second thought when it's the thing they need. At least that's what I am told by usability professionals who test this design element again and again, one client at a time.
>
> People will tell you that they recognize and use the unlabeled icon, but if you observe their behavior you will see that much of the time they don't.
>
> The bottom line is to avoid creating text-free interfaces. Icons rarely are as recognizable and unambiguous as we think.
>
> Put me solidly in the camp of liking the proposed approach. If the design is responsive, it shouldn't lead to that much trouble.
>
> Cliff
>
> Cliff Tyllick
> Accessibility Specialist
> Texas Department of Assistive and Rehabilitative Services
>
> Sent from my iPhone
> Although its spellcheck often saves me, all goofs in sent messages are its fault.
>
> > On Feb 10, 2016, at 9:52 AM, _mallory < = EMAIL ADDRESS REMOVED = > wrote:
> >
> > "The icons are more easily recognizable at a glance than text labels"
> >
> > Actually I remember reading a study (or a reference to a study) showing
> > that in an application, what users really remember is *where* the icon
> > is, rather than what the icon looks like. Other things like the colour
> > and size were also more remembered.
> >
> > I like the idea of the UA exposing these names to any user who asks.
> >
> > _mallory
> >
> >> On Wed, Feb 10, 2016 at 09:15:23AM -0500, Robert Fentress wrote:
> >> All good points. However, I can hear the person whose site I'm
> >> evaluating saying something like, "We'll, my application is very
> >> complex and making these things into icons allows me to fit more
> >> functionality into a limited space, thus making it so users do not
> >> have to spend a lot of time rooting through separate pages to get to
> >> the functionality they need. The icons are more easily recognizable
> >> at a glance than text labels would be and thus reduce the cognitive
> >> load, once you are familiar with what they mean."
> >>
> >> I like the idea of having a way of enabling text labels if desired.
> >> However, I have a hard time imagining how that could happen without a
> >> major interface redesign at this point.
> >>
> >> Oh well, I guess I just need to make them aware of the issues and
> >> provide possible solutions. It's up to them figure out how (or if)
> >> they can implement them given their resources.
> >>
> >> There is also the question of at what point this becomes a user agent
> >> responsibility. I mean, the information is there and I'd argue speech
> >> control software should provide the option to make it available
> >> visually. If every label must be visible to everyone all the time,
> >> what is the point of things like aria-label and chained ids for
> >> aria-labelledby?
> > > > > > > > > > > >