E-mail List Archives
Thread: Screen reader bugs
Number of posts in this thread: 7 (In chronological order)
From: Sumit Patel
Date: Mon, May 29 2023 12:37AM
Subject: Screen reader bugs
No previous message | Next message →
Hai all,
I would like to know the thoughts on how everyone approaches screen
reader bugs which causes accessibility issues .
Here screen reader bugs means I refer, -
though we have added recommended or apppropriate ARIA/HTML code , some
of the screen readers don't identify it.
For example, Talkback does not support ARIA/HTML required attribute,
group label which added using either fieldset and legend tags or
"group" role etc .
Not just Talkback, with most of the screen readers , I have seen this
issue. It may work with most of the screen readers except 1 or 2
readers.
I am not talking about a scenario where wehavn't added appropriate
code and screen reader does not render it as expected.
Talking about screen reader does not render it as expected even after
adding appropriate code , maybe by refering aria techniques or or any
other documents
Here, what should be our approach ?
Even I have experienced scenarios where the code was working fine
initially . but, stopped working after a screen reader update .
Do we need to ignore this issue as it just happens in only 1 or 2
screen readers and by thinking that it may get fixed in future after
some updates of thos readers
or
need to think of other alternatives which works well with all the
screen readers?
Regards,
Sumit.
From: Graham Armfield
Date: Mon, May 29 2023 3:02AM
Subject: Re: Screen reader bugs
← Previous message | Next message →
If you're certain your code is correct then one approach would be to look
at the bug lists for the relevant screen reader, and raise a new one if you
can't find it.
Sometimes bugs turn out to be actually with the browser, but at least you
might find out more.
Regards
Graham Armfield
Coolfields Consulting
On Mon, 29 May 2023, 7:37 am Sumit Patel, < = EMAIL ADDRESS REMOVED = >
wrote:
> Hai all,
>
> I would like to know the thoughts on how everyone approaches screen
> reader bugs which causes accessibility issues .
>
> Here screen reader bugs means I refer, -
> though we have added recommended or apppropriate ARIA/HTML code , some
> of the screen readers don't identify it.
> For example, Talkback does not support ARIA/HTML required attribute,
> group label which added using either fieldset and legend tags or
> "group" role etc .
> Not just Talkback, with most of the screen readers , I have seen this
> issue. It may work with most of the screen readers except 1 or 2
> readers.
>
> I am not talking about a scenario where wehavn't added appropriate
> code and screen reader does not render it as expected.
>
> Talking about screen reader does not render it as expected even after
> adding appropriate code , maybe by refering aria techniques or or any
> other documents
>
> Here, what should be our approach ?
> Even I have experienced scenarios where the code was working fine
> initially . but, stopped working after a screen reader update .
>
>
> Do we need to ignore this issue as it just happens in only 1 or 2
> screen readers and by thinking that it may get fixed in future after
> some updates of thos readers
> or
> need to think of other alternatives which works well with all the
> screen readers?
>
> Regards,
> Sumit.
> > > > >
From: tim.harshbarger@deque.com
Date: Mon, May 29 2023 8:37PM
Subject: Re: Screen reader bugs
← Previous message | Next message →
I refer to any bug that seems to be due to the browser, OS's accessibility API, or screen reader as a user agent defect. That is the code for the application is coded to technical specifications but does not work due to some issue or combination of issues with the browser, OS, or screen reader.
Before I tag something a user agent defect, I want to come up with solid proof and documentation that it really is a user agent defect. For example, I might want to be able to recreate the problem using a minimum viable test page.
Once I figure out that it is likely a user agent defect, it is time to decide what to do about it. For example, if there is no screen reader/browser/OS combination that supports that technique, then I don't recommend that technique. If it only occurs in some combinations, what is the user impact? Is there a work around for the issue? How difficult is the work around to implement? Is the work around a hack or just another technique supported by the specifications?
I don't always go as far as deciding if the issue exists in the screen reader, browser, OS, or some combination. That does involve extra time and effort and if the focus is on implementing an application for the next sprint, there isn't always the time to spend on that effort.
It has been a while since I had the opportunity to fully test this, but I don't believe that most screen readers support reporting the required or aria-required state from the fieldset, legend, or element with role="group". When I find a situation like that and there are other viable techniques, I just recommend the other techniques. In fact, in situations where there is little or no support for something I tend to think of that more as a user agent behaviour rather than a user agent defect--but that is just a personal perspective.
Unfortunately, there really isn't a hard set of rules for this. It is quite possible for 2 accessibility professionals to look at the same information for a user agent defect and they end up with different decisions. The important part is to gather as much information as you can regarding the nature of the issue, its user impact, and the alternatives and then try to make a decision based on requirements and trade-offs that seem sensible for the environment.
I've actually had the past opportunity to work with some people who are on or have been part of this list and have discussions on these types of defects. It always ends up being an interesting and insightful discussion.
Thanks!
Tim
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Sumit Patel
Sent: Monday, May 29, 2023 1:37 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: [WebAIM] Screen reader bugs
Hai all,
I would like to know the thoughts on how everyone approaches screen reader bugs which causes accessibility issues .
Here screen reader bugs means I refer, - though we have added recommended or apppropriate ARIA/HTML code , some of the screen readers don't identify it.
For example, Talkback does not support ARIA/HTML required attribute, group label which added using either fieldset and legend tags or "group" role etc .
Not just Talkback, with most of the screen readers , I have seen this issue. It may work with most of the screen readers except 1 or 2 readers.
I am not talking about a scenario where wehavn't added appropriate code and screen reader does not render it as expected.
Talking about screen reader does not render it as expected even after adding appropriate code , maybe by refering aria techniques or or any other documents
Here, what should be our approach ?
Even I have experienced scenarios where the code was working fine initially . but, stopped working after a screen reader update .
Do we need to ignore this issue as it just happens in only 1 or 2 screen readers and by thinking that it may get fixed in future after some updates of thos readers or need to think of other alternatives which works well with all the screen readers?
Regards,
Sumit.
From: Sumit Patel
Date: Mon, May 29 2023 11:40PM
Subject: Re: Screen reader bugs
← Previous message | Next message →
Thanks for your response.
I was also thinking to take decision based on the impact and how many
screen reader the specific issue happen with .
As an example, the required attribute issue occurs only with Talkback
screen reader. So, I thought of not spending time to find an
alternative as it works fine with all the other screen readers.
Moreover, Talkback has issue with aria-required attribute as well.
Even we have already a ticket number in its repository as a
reference.
But, in case of any other issue where it does not work well with many
screen readers , can think of alternatives if we have something.
Just thought of confirming with the community to know how others are
dealing with this
On 30/05/2023, = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > wrote:
> I refer to any bug that seems to be due to the browser, OS's accessibility
> API, or screen reader as a user agent defect. That is the code for the
> application is coded to technical specifications but does not work due to
> some issue or combination of issues with the browser, OS, or screen reader.
>
> Before I tag something a user agent defect, I want to come up with solid
> proof and documentation that it really is a user agent defect. For example,
> I might want to be able to recreate the problem using a minimum viable test
> page.
>
> Once I figure out that it is likely a user agent defect, it is time to
> decide what to do about it. For example, if there is no screen
> reader/browser/OS combination that supports that technique, then I don't
> recommend that technique. If it only occurs in some combinations, what is
> the user impact? Is there a work around for the issue? How difficult is the
> work around to implement? Is the work around a hack or just another
> technique supported by the specifications?
>
> I don't always go as far as deciding if the issue exists in the screen
> reader, browser, OS, or some combination. That does involve extra time and
> effort and if the focus is on implementing an application for the next
> sprint, there isn't always the time to spend on that effort.
>
> It has been a while since I had the opportunity to fully test this, but I
> don't believe that most screen readers support reporting the required or
> aria-required state from the fieldset, legend, or element with role="group".
> When I find a situation like that and there are other viable techniques, I
> just recommend the other techniques. In fact, in situations where there is
> little or no support for something I tend to think of that more as a user
> agent behaviour rather than a user agent defect--but that is just a personal
> perspective.
>
> Unfortunately, there really isn't a hard set of rules for this. It is quite
> possible for 2 accessibility professionals to look at the same information
> for a user agent defect and they end up with different decisions. The
> important part is to gather as much information as you can regarding the
> nature of the issue, its user impact, and the alternatives and then try to
> make a decision based on requirements and trade-offs that seem sensible for
> the environment.
>
> I've actually had the past opportunity to work with some people who are on
> or have been part of this list and have discussions on these types of
> defects. It always ends up being an interesting and insightful discussion.
>
> Thanks!
> Tim
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Sumit
> Patel
> Sent: Monday, May 29, 2023 1:37 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: [WebAIM] Screen reader bugs
>
> Hai all,
>
> I would like to know the thoughts on how everyone approaches screen reader
> bugs which causes accessibility issues .
>
> Here screen reader bugs means I refer, - though we have added recommended or
> apppropriate ARIA/HTML code , some of the screen readers don't identify it.
> For example, Talkback does not support ARIA/HTML required attribute, group
> label which added using either fieldset and legend tags or "group" role
> etc .
> Not just Talkback, with most of the screen readers , I have seen this issue.
> It may work with most of the screen readers except 1 or 2 readers.
>
> I am not talking about a scenario where wehavn't added appropriate code and
> screen reader does not render it as expected.
>
> Talking about screen reader does not render it as expected even after adding
> appropriate code , maybe by refering aria techniques or or any other
> documents
>
> Here, what should be our approach ?
> Even I have experienced scenarios where the code was working fine initially
> . but, stopped working after a screen reader update .
>
>
> Do we need to ignore this issue as it just happens in only 1 or 2 screen
> readers and by thinking that it may get fixed in future after some updates
> of thos readers or need to think of other alternatives which works well
> with all the screen readers?
>
> Regards,
> Sumit.
> > > http://webaim.org/discussion/archives
> >
> > > > >
From: Steve Green
Date: Tue, May 30 2023 12:00AM
Subject: Re: Screen reader bugs
← Previous message | Next message →
In this case the problem is that you are not using the "aria-required" attribute correctly. If it has the behaviour you want in some screen readers, that is due to luck. Talkback is not behaving incorrectly.
The ARIA specification states that "aria-required is only applicable to interactive elements", so you cannot put it on a fieldset or a group. Furthermore, the specification lists the roles to which aria-required can be applied, which are combobox, gridcell, listbox, radiogroup, spinbutton, textbox and tree.
https://www.w3.org/TR/wai-aria-1.1/#aria-required
Steve Green
Managing Director
Test Partners Ltd
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Sumit Patel
Sent: Tuesday, May 30, 2023 6:41 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Screen reader bugs
Thanks for your response.
I was also thinking to take decision based on the impact and how many screen reader the specific issue happen with .
As an example, the required attribute issue occurs only with Talkback screen reader. So, I thought of not spending time to find an alternative as it works fine with all the other screen readers.
Moreover, Talkback has issue with aria-required attribute as well.
Even we have already a ticket number in its repository as a reference.
But, in case of any other issue where it does not work well with many screen readers , can think of alternatives if we have something.
Just thought of confirming with the community to know how others are dealing with this
On 30/05/2023, = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > wrote:
> I refer to any bug that seems to be due to the browser, OS's
> accessibility API, or screen reader as a user agent defect. That is
> the code for the application is coded to technical specifications but
> does not work due to some issue or combination of issues with the browser, OS, or screen reader.
>
> Before I tag something a user agent defect, I want to come up with
> solid proof and documentation that it really is a user agent defect.
> For example, I might want to be able to recreate the problem using a
> minimum viable test page.
>
> Once I figure out that it is likely a user agent defect, it is time to
> decide what to do about it. For example, if there is no screen
> reader/browser/OS combination that supports that technique, then I
> don't recommend that technique. If it only occurs in some
> combinations, what is the user impact? Is there a work around for the
> issue? How difficult is the work around to implement? Is the work
> around a hack or just another technique supported by the specifications?
>
> I don't always go as far as deciding if the issue exists in the screen
> reader, browser, OS, or some combination. That does involve extra time
> and effort and if the focus is on implementing an application for the
> next sprint, there isn't always the time to spend on that effort.
>
> It has been a while since I had the opportunity to fully test this,
> but I don't believe that most screen readers support reporting the
> required or aria-required state from the fieldset, legend, or element with role="group".
> When I find a situation like that and there are other viable
> techniques, I just recommend the other techniques. In fact, in
> situations where there is little or no support for something I tend to
> think of that more as a user agent behaviour rather than a user agent
> defect--but that is just a personal perspective.
>
> Unfortunately, there really isn't a hard set of rules for this. It is
> quite possible for 2 accessibility professionals to look at the same
> information for a user agent defect and they end up with different
> decisions. The important part is to gather as much information as you
> can regarding the nature of the issue, its user impact, and the
> alternatives and then try to make a decision based on requirements and
> trade-offs that seem sensible for the environment.
>
> I've actually had the past opportunity to work with some people who
> are on or have been part of this list and have discussions on these
> types of defects. It always ends up being an interesting and insightful discussion.
>
> Thanks!
> Tim
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Sumit Patel
> Sent: Monday, May 29, 2023 1:37 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: [WebAIM] Screen reader bugs
>
> Hai all,
>
> I would like to know the thoughts on how everyone approaches screen
> reader bugs which causes accessibility issues .
>
> Here screen reader bugs means I refer, - though we have added
> recommended or apppropriate ARIA/HTML code , some of the screen readers don't identify it.
> For example, Talkback does not support ARIA/HTML required attribute,
> group label which added using either fieldset and legend tags or
> "group" role etc .
> Not just Talkback, with most of the screen readers , I have seen this issue.
> It may work with most of the screen readers except 1 or 2 readers.
>
> I am not talking about a scenario where wehavn't added appropriate
> code and screen reader does not render it as expected.
>
> Talking about screen reader does not render it as expected even after
> adding appropriate code , maybe by refering aria techniques or or any
> other documents
>
> Here, what should be our approach ?
> Even I have experienced scenarios where the code was working fine
> initially . but, stopped working after a screen reader update .
>
>
> Do we need to ignore this issue as it just happens in only 1 or 2
> screen readers and by thinking that it may get fixed in future after
> some updates of thos readers or need to think of other alternatives
> which works well with all the screen readers?
>
> Regards,
> Sumit.
> > > archives at http://webaim.org/discussion/archives
> >
> > > archives at http://webaim.org/discussion/archives
> >
From: Julie Romanowski
Date: Tue, May 30 2023 5:06AM
Subject: Re: Screen reader bugs
← Previous message | Next message →
What Tim said. ð
In my years of testing, I came to the same conclusions as Tim. As always,
he states things much more eloquently than I.
On Mon, May 29, 2023 at 9:37 PM < = EMAIL ADDRESS REMOVED = > wrote:
> I refer to any bug that seems to be due to the browser, OS's accessibility
> API, or screen reader as a user agent defect. That is the code for the
> application is coded to technical specifications but does not work due to
> some issue or combination of issues with the browser, OS, or screen reader.
>
> Before I tag something a user agent defect, I want to come up with solid
> proof and documentation that it really is a user agent defect. For example,
> I might want to be able to recreate the problem using a minimum viable test
> page.
>
> Once I figure out that it is likely a user agent defect, it is time to
> decide what to do about it. For example, if there is no screen
> reader/browser/OS combination that supports that technique, then I don't
> recommend that technique. If it only occurs in some combinations, what is
> the user impact? Is there a work around for the issue? How difficult is the
> work around to implement? Is the work around a hack or just another
> technique supported by the specifications?
>
> I don't always go as far as deciding if the issue exists in the screen
> reader, browser, OS, or some combination. That does involve extra time and
> effort and if the focus is on implementing an application for the next
> sprint, there isn't always the time to spend on that effort.
>
> It has been a while since I had the opportunity to fully test this, but I
> don't believe that most screen readers support reporting the required or
> aria-required state from the fieldset, legend, or element with
> role="group". When I find a situation like that and there are other viable
> techniques, I just recommend the other techniques. In fact, in situations
> where there is little or no support for something I tend to think of that
> more as a user agent behaviour rather than a user agent defect--but that is
> just a personal perspective.
>
> Unfortunately, there really isn't a hard set of rules for this. It is
> quite possible for 2 accessibility professionals to look at the same
> information for a user agent defect and they end up with different
> decisions. The important part is to gather as much information as you can
> regarding the nature of the issue, its user impact, and the alternatives
> and then try to make a decision based on requirements and trade-offs that
> seem sensible for the environment.
>
> I've actually had the past opportunity to work with some people who are on
> or have been part of this list and have discussions on these types of
> defects. It always ends up being an interesting and insightful discussion.
>
> Thanks!
> Tim
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Sumit Patel
> Sent: Monday, May 29, 2023 1:37 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: [WebAIM] Screen reader bugs
>
> Hai all,
>
> I would like to know the thoughts on how everyone approaches screen reader
> bugs which causes accessibility issues .
>
> Here screen reader bugs means I refer, - though we have added recommended
> or apppropriate ARIA/HTML code , some of the screen readers don't identify
> it.
> For example, Talkback does not support ARIA/HTML required attribute,
> group label which added using either fieldset and legend tags or "group"
> role etc .
> Not just Talkback, with most of the screen readers , I have seen this
> issue. It may work with most of the screen readers except 1 or 2 readers.
>
> I am not talking about a scenario where wehavn't added appropriate code
> and screen reader does not render it as expected.
>
> Talking about screen reader does not render it as expected even after
> adding appropriate code , maybe by refering aria techniques or or any other
> documents
>
> Here, what should be our approach ?
> Even I have experienced scenarios where the code was working fine
> initially . but, stopped working after a screen reader update .
>
>
> Do we need to ignore this issue as it just happens in only 1 or 2 screen
> readers and by thinking that it may get fixed in future after some updates
> of thos readers or need to think of other alternatives which works well
> with all the screen readers?
>
> Regards,
> Sumit.
> > > at http://webaim.org/discussion/archives
> >
> > > > >
--
Julie Romanowski
From: steve@sawczyn.com
Date: Tue, May 30 2023 10:39AM
Subject: Re: Screen reader bugs
← Previous message | No next message
In my humble opinion, Timâs 1sT point cannot be stated enough: be sure that it truly is a user agent defect. Countless times Iâve heard from developers that something or other is an NVDA or VoiceOver or TalkBack defect when in most of those cases, they coded something not according to spec and it worked with one browser/screen reader combo more by luck than by design. Not trashing developers here at all as I realize this stuff is complicated and often nuanced, but I think screen reader defects are called out as the problem far more often than they should be.
Steve
> On May 29, 2023, at 9:37 PM, = EMAIL ADDRESS REMOVED = wrote:
>
> I refer to any bug that seems to be due to the browser, OS's accessibility API, or screen reader as a user agent defect. That is the code for the application is coded to technical specifications but does not work due to some issue or combination of issues with the browser, OS, or screen reader.
>
> Before I tag something a user agent defect, I want to come up with solid proof and documentation that it really is a user agent defect. For example, I might want to be able to recreate the problem using a minimum viable test page.
>
> Once I figure out that it is likely a user agent defect, it is time to decide what to do about it. For example, if there is no screen reader/browser/OS combination that supports that technique, then I don't recommend that technique. If it only occurs in some combinations, what is the user impact? Is there a work around for the issue? How difficult is the work around to implement? Is the work around a hack or just another technique supported by the specifications?
>
> I don't always go as far as deciding if the issue exists in the screen reader, browser, OS, or some combination. That does involve extra time and effort and if the focus is on implementing an application for the next sprint, there isn't always the time to spend on that effort.
>
> It has been a while since I had the opportunity to fully test this, but I don't believe that most screen readers support reporting the required or aria-required state from the fieldset, legend, or element with role="group". When I find a situation like that and there are other viable techniques, I just recommend the other techniques. In fact, in situations where there is little or no support for something I tend to think of that more as a user agent behaviour rather than a user agent defect--but that is just a personal perspective.
>
> Unfortunately, there really isn't a hard set of rules for this. It is quite possible for 2 accessibility professionals to look at the same information for a user agent defect and they end up with different decisions. The important part is to gather as much information as you can regarding the nature of the issue, its user impact, and the alternatives and then try to make a decision based on requirements and trade-offs that seem sensible for the environment.
>
> I've actually had the past opportunity to work with some people who are on or have been part of this list and have discussions on these types of defects. It always ends up being an interesting and insightful discussion.
>
> Thanks!
> Tim
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Sumit Patel
> Sent: Monday, May 29, 2023 1:37 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: [WebAIM] Screen reader bugs
>
> Hai all,
>
> I would like to know the thoughts on how everyone approaches screen reader bugs which causes accessibility issues .
>
> Here screen reader bugs means I refer, - though we have added recommended or apppropriate ARIA/HTML code , some of the screen readers don't identify it.
> For example, Talkback does not support ARIA/HTML required attribute, group label which added using either fieldset and legend tags or "group" role etc .
> Not just Talkback, with most of the screen readers , I have seen this issue. It may work with most of the screen readers except 1 or 2 readers.
>
> I am not talking about a scenario where wehavn't added appropriate code and screen reader does not render it as expected.
>
> Talking about screen reader does not render it as expected even after adding appropriate code , maybe by refering aria techniques or or any other documents
>
> Here, what should be our approach ?
> Even I have experienced scenarios where the code was working fine initially . but, stopped working after a screen reader update .
>
>
> Do we need to ignore this issue as it just happens in only 1 or 2 screen readers and by thinking that it may get fixed in future after some updates of thos readers or need to think of other alternatives which works well with all the screen readers?
>
> Regards,
> Sumit.
> > > >
> > > >