E-mail List Archives
Thread: Zoon Text and Dragon Natural
Number of posts in this thread: 7 (In chronological order)
From: Ajay Sharma
Date: Sun, Sep 02 2018 11:46PM
Subject: Zoon Text and Dragon Natural
No previous message | Next message →
Hi There,
We are looking for possibility to add Zoom Text and Dragon Natural
into our test matrix. So need your opinion on how good is it to add
them if we are already testing with JAWS and WSR.
Best Regards,
Ajay
From: Srinivasu Chakravarthula
Date: Mon, Sep 03 2018 12:09AM
Subject: Re: Zoon Text and Dragon Natural
← Previous message | Next message →
Ajay,
Dragon Naturally Speaking is a speech recognition software where you can
provide input by voice to use the web. ZoomText is a screen magnification
software. So to get the prospective of how website / app is working for
people with low vision, elderly etc., it would be worth using a screen
magnification software such as Zoom Text and to get th eprospective of
people with motor difficulties and prefer to use speech input, it's worth
testing with speech recognition software.
Point I would like to make it these cannot be alternatives to screen
reading software such as NVDA, JAWS etc., target users are different. You
need to make a choice based on requirement of your customers. More
importantly, testing needs to be done against standards.
Thanks,
Vasu
Regards,
Srinivasu Chakravarthula - Twitter: http://twitter.com/CSrinivasu/
Website: http://www.srinivasu.org | http://serveominclusion.com
Let's create an inclusive web!
Lead Accessibility Consultant, Informatica
On Mon, Sep 3, 2018 at 11:16 AM Ajay Sharma < = EMAIL ADDRESS REMOVED = >
wrote:
> Hi There,
>
> We are looking for possibility to add Zoom Text and Dragon Natural
> into our test matrix. So need your opinion on how good is it to add
> them if we are already testing with JAWS and WSR.
>
> Best Regards,
> Ajay
> > > > >
From: glen walker
Date: Mon, Sep 03 2018 9:59AM
Subject: Re: Zoon Text and Dragon Natural
← Previous message | Next message →
Given the time and budget, it's always great to test with other assistive
technology (AT) such as speech recognition and magnification software. You
could include refreshable braille devices too but would need some expertise
on that. All of these other ATs can find problems that screen readers
might not catch.
With speech recognition, if you have elements with an aria-label or
aria-labelledby that don't match the visual presentation, then you can
sometimes get into a situation where the Dragon user can't say "click
element-name" because the element name that's displayed visually doesn't
match the accessible name (aria-label). You can kind of check for this
with screen readers by displaying the dialog that shows all the links or
all the buttons (Ins+F7), which will show the accessible name, and compare
that to visually what's on the screen. If they don't match (or have
sufficient words in common), then a Dragon user might have trouble.
With magnification software, you can sometimes catch focus issues.
ZoomText should follow the focus so that when the focus is moved to another
element, if that element is out of view of ZoomText, it should scroll the
element into view. If the page is only scrolling to an element and not
putting the focus on the element, the element might not appear in view for
ZoomText. To test this without ZoomText, if you have a focus indicator and
any action you perform on the page that causes the focus to move shows a
visual focus indicator on the resulting element, then ZoomText should be ok.
With braille devices, we often catch the wrong character being used for
special symbols, such as the degree symbol.
Glen
From: Ajay Sharma
Date: Mon, Sep 03 2018 11:52PM
Subject: Re: Zoon Text and Dragon Natural
← Previous message | Next message →
Thanks a lot Glen and Vasu, that was really helpful info.
Best Regards,
Ajay
On 9/3/18, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> Given the time and budget, it's always great to test with other assistive
> technology (AT) such as speech recognition and magnification software. You
> could include refreshable braille devices too but would need some expertise
> on that. All of these other ATs can find problems that screen readers
> might not catch.
>
> With speech recognition, if you have elements with an aria-label or
> aria-labelledby that don't match the visual presentation, then you can
> sometimes get into a situation where the Dragon user can't say "click
> element-name" because the element name that's displayed visually doesn't
> match the accessible name (aria-label). You can kind of check for this
> with screen readers by displaying the dialog that shows all the links or
> all the buttons (Ins+F7), which will show the accessible name, and compare
> that to visually what's on the screen. If they don't match (or have
> sufficient words in common), then a Dragon user might have trouble.
>
> With magnification software, you can sometimes catch focus issues.
> ZoomText should follow the focus so that when the focus is moved to another
> element, if that element is out of view of ZoomText, it should scroll the
> element into view. If the page is only scrolling to an element and not
> putting the focus on the element, the element might not appear in view for
> ZoomText. To test this without ZoomText, if you have a focus indicator and
> any action you perform on the page that causes the focus to move shows a
> visual focus indicator on the resulting element, then ZoomText should be
> ok.
>
> With braille devices, we often catch the wrong character being used for
> special symbols, such as the degree symbol.
>
> Glen
> > > > >
From: Robert Fentress
Date: Wed, Sep 05 2018 11:17AM
Subject: Re: Zoon Text and Dragon Natural
← Previous message | Next message →
An example of where testing with Dragon revealed an issue is when I found
Dragon 14.0 doesn't support the use of aria-labelledby on a button, though
WSR does. So, for example, if you have an icon button labelled by a tooltip
<https://inclusive-components.design/tooltips-toggletips/#tooltipasprimarylabel>,
the person using Dragon will not be able to activate the button by saying
"click [button label]". Testing revealed it does work with aria-label on
the button itself (and other methods), so that informed some design
decisions. Of course, that is a bug with Dragon, so maybe you can view it
as not your responsibility, but if you heavily rely on this technique of
icon buttons labelled by tooltips, then you could still be inconveniencing
a decent segment of your users.
On Tue, Sep 4, 2018 at 1:52 AM Ajay Sharma < = EMAIL ADDRESS REMOVED = >
wrote:
> Thanks a lot Glen and Vasu, that was really helpful info.
>
> Best Regards,
> Ajay
>
> On 9/3/18, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> > Given the time and budget, it's always great to test with other assistive
> > technology (AT) such as speech recognition and magnification software.
> You
> > could include refreshable braille devices too but would need some
> expertise
> > on that. All of these other ATs can find problems that screen readers
> > might not catch.
> >
> > With speech recognition, if you have elements with an aria-label or
> > aria-labelledby that don't match the visual presentation, then you can
> > sometimes get into a situation where the Dragon user can't say "click
> > element-name" because the element name that's displayed visually doesn't
> > match the accessible name (aria-label). You can kind of check for this
> > with screen readers by displaying the dialog that shows all the links or
> > all the buttons (Ins+F7), which will show the accessible name, and
> compare
> > that to visually what's on the screen. If they don't match (or have
> > sufficient words in common), then a Dragon user might have trouble.
> >
> > With magnification software, you can sometimes catch focus issues.
> > ZoomText should follow the focus so that when the focus is moved to
> another
> > element, if that element is out of view of ZoomText, it should scroll the
> > element into view. If the page is only scrolling to an element and not
> > putting the focus on the element, the element might not appear in view
> for
> > ZoomText. To test this without ZoomText, if you have a focus indicator
> and
> > any action you perform on the page that causes the focus to move shows a
> > visual focus indicator on the resulting element, then ZoomText should be
> > ok.
> >
> > With braille devices, we often catch the wrong character being used for
> > special symbols, such as the degree symbol.
> >
> > Glen
> > > > > > > > > >
> > > > >
--
*Rob Fentress*
*Web Accessibility Solutions Designer*
Accessible Technologies at Virginia Tech
Electronic Business Card (vCard)
<http://search.vt.edu/search/person.vcf?person=1154847>;
LinkedIn Profile
<https://www.linkedin.com/in/rob-fentress-aa0b609?trk=profile-badge>
VT Zoom Personal Conferencing <https://virginiatech.zoom.us/my/rob.fentress>
From: Steve Green
Date: Wed, Sep 05 2018 11:34AM
Subject: Re: Zoon Text and Dragon Natural
← Previous message | Next message →
There are lots of differences in behaviour between Dragon and WSR. You can't test with one and make any assumptions about how the other will behave.
For example, one of our clients had to use a disgusting CRM system from Siebel for their work. Neither Dragon nor WSR was usable on their own, but the client could just about use the system if she used both. My recollection is that broadly speaking, she had to use WSM to navigate around the page, but she had to switch to Dragon in order to dictate into the form fields. There were no html elements in the body element in the initial source code - the entire page content was generated by scripts.
Steve Green
Managing Director
Test Partners Ltd
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Robert Fentress
Sent: 05 September 2018 18:17
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Zoon Text and Dragon Natural
An example of where testing with Dragon revealed an issue is when I found Dragon 14.0 doesn't support the use of aria-labelledby on a button, though WSR does. So, for example, if you have an icon button labelled by a tooltip <https://inclusive-components.design/tooltips-toggletips/#tooltipasprimarylabel>,
the person using Dragon will not be able to activate the button by saying "click [button label]". Testing revealed it does work with aria-label on the button itself (and other methods), so that informed some design decisions. Of course, that is a bug with Dragon, so maybe you can view it as not your responsibility, but if you heavily rely on this technique of icon buttons labelled by tooltips, then you could still be inconveniencing a decent segment of your users.
On Tue, Sep 4, 2018 at 1:52 AM Ajay Sharma < = EMAIL ADDRESS REMOVED = >
wrote:
> Thanks a lot Glen and Vasu, that was really helpful info.
>
> Best Regards,
> Ajay
>
> On 9/3/18, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> > Given the time and budget, it's always great to test with other
> > assistive technology (AT) such as speech recognition and magnification software.
> You
> > could include refreshable braille devices too but would need some
> expertise
> > on that. All of these other ATs can find problems that screen
> > readers might not catch.
> >
> > With speech recognition, if you have elements with an aria-label or
> > aria-labelledby that don't match the visual presentation, then you
> > can sometimes get into a situation where the Dragon user can't say
> > "click element-name" because the element name that's displayed
> > visually doesn't match the accessible name (aria-label). You can
> > kind of check for this with screen readers by displaying the dialog
> > that shows all the links or all the buttons (Ins+F7), which will
> > show the accessible name, and
> compare
> > that to visually what's on the screen. If they don't match (or have
> > sufficient words in common), then a Dragon user might have trouble.
> >
> > With magnification software, you can sometimes catch focus issues.
> > ZoomText should follow the focus so that when the focus is moved to
> another
> > element, if that element is out of view of ZoomText, it should
> > scroll the element into view. If the page is only scrolling to an
> > element and not putting the focus on the element, the element might
> > not appear in view
> for
> > ZoomText. To test this without ZoomText, if you have a focus
> > indicator
> and
> > any action you perform on the page that causes the focus to move
> > shows a visual focus indicator on the resulting element, then
> > ZoomText should be ok.
> >
> > With braille devices, we often catch the wrong character being used
> > for special symbols, such as the degree symbol.
> >
> > Glen
> > > > > > archives at http://webaim.org/discussion/archives
> > > >
> > > archives at http://webaim.org/discussion/archives
> >
--
*Rob Fentress*
*Web Accessibility Solutions Designer*
Accessible Technologies at Virginia Tech Electronic Business Card (vCard) <http://search.vt.edu/search/person.vcf?person=1154847>;
LinkedIn Profile
<https://www.linkedin.com/in/rob-fentress-aa0b609?trk=profile-badge>
VT Zoom Personal Conferencing <https://virginiatech.zoom.us/my/rob.fentress>
From: Mallory
Date: Sun, Sep 09 2018 9:06AM
Subject: Re: Zoon Text and Dragon Natural
← Previous message | No next message
Yeah Eric Wright uses a Dragon macro to call WRS commands that Dragon misses, like "show numbers" (shows all clickable elements... we heard in a github issue that there is a "show links" but this totally does nothing on 13 on IE11, seems to work for Eric but he's moved on to 15 and uses chrome now, the only usable browser nowadays if you don't stick to IE).
Also found aria-label worked on text inputs but not textareas. Lol.
cheers,
Mallory
On Wed, Sep 5, 2018, at 7:34 PM, Steve Green wrote:
> There are lots of differences in behaviour between Dragon and WSR. You
> can't test with one and make any assumptions about how the other will
> behave.
>
> For example, one of our clients had to use a disgusting CRM system from
> Siebel for their work. Neither Dragon nor WSR was usable on their own,
> but the client could just about use the system if she used both. My
> recollection is that broadly speaking, she had to use WSM to navigate
> around the page, but she had to switch to Dragon in order to dictate
> into the form fields. There were no html elements in the body element in
> the initial source code - the entire page content was generated by
> scripts.
>
> Steve Green
> Managing Director
> Test Partners Ltd
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Robert Fentress
> Sent: 05 September 2018 18:17
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Zoon Text and Dragon Natural
>
> An example of where testing with Dragon revealed an issue is when I
> found Dragon 14.0 doesn't support the use of aria-labelledby on a
> button, though WSR does. So, for example, if you have an icon button
> labelled by a tooltip
> <https://inclusive-components.design/tooltips-toggletips/#tooltipasprimarylabel>,
> the person using Dragon will not be able to activate the button by
> saying "click [button label]". Testing revealed it does work with aria-
> label on the button itself (and other methods), so that informed some
> design decisions. Of course, that is a bug with Dragon, so maybe you
> can view it as not your responsibility, but if you heavily rely on this
> technique of icon buttons labelled by tooltips, then you could still be
> inconveniencing a decent segment of your users.
>
> On Tue, Sep 4, 2018 at 1:52 AM Ajay Sharma < = EMAIL ADDRESS REMOVED = >
> wrote:
>
> > Thanks a lot Glen and Vasu, that was really helpful info.
> >
> > Best Regards,
> > Ajay
> >
> > On 9/3/18, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> > > Given the time and budget, it's always great to test with other
> > > assistive technology (AT) such as speech recognition and magnification software.
> > You
> > > could include refreshable braille devices too but would need some
> > expertise
> > > on that. All of these other ATs can find problems that screen
> > > readers might not catch.
> > >
> > > With speech recognition, if you have elements with an aria-label or
> > > aria-labelledby that don't match the visual presentation, then you
> > > can sometimes get into a situation where the Dragon user can't say
> > > "click element-name" because the element name that's displayed
> > > visually doesn't match the accessible name (aria-label). You can
> > > kind of check for this with screen readers by displaying the dialog
> > > that shows all the links or all the buttons (Ins+F7), which will
> > > show the accessible name, and
> > compare
> > > that to visually what's on the screen. If they don't match (or have
> > > sufficient words in common), then a Dragon user might have trouble.
> > >
> > > With magnification software, you can sometimes catch focus issues.
> > > ZoomText should follow the focus so that when the focus is moved to
> > another
> > > element, if that element is out of view of ZoomText, it should
> > > scroll the element into view. If the page is only scrolling to an
> > > element and not putting the focus on the element, the element might
> > > not appear in view
> > for
> > > ZoomText. To test this without ZoomText, if you have a focus
> > > indicator
> > and
> > > any action you perform on the page that causes the focus to move
> > > shows a visual focus indicator on the resulting element, then
> > > ZoomText should be ok.
> > >
> > > With braille devices, we often catch the wrong character being used
> > > for special symbols, such as the degree symbol.
> > >
> > > Glen
> > > > > > > > > archives at http://webaim.org/discussion/archives
> > > > > >
> > > > > > archives at http://webaim.org/discussion/archives
> > > >
>
>
> --
> *Rob Fentress*
> *Web Accessibility Solutions Designer*
> Accessible Technologies at Virginia Tech Electronic Business Card
> (vCard) <http://search.vt.edu/search/person.vcf?person=1154847>;
> LinkedIn Profile
> <https://www.linkedin.com/in/rob-fentress-aa0b609?trk=profile-badge>
> VT Zoom Personal Conferencing
> <https://virginiatech.zoom.us/my/rob.fentress>
> > > at http://webaim.org/discussion/archives
> > > > >