WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Screen reader bugs

for

From: Steve Green
Date: May 30, 2023 12:00AM

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 REMOVED> > On Behalf Of Sumit Patel
Sent: Tuesday, May 30, 2023 6:41 AM
To: WebAIM Discussion List < <EMAIL 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 REMOVED> < <EMAIL 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 REMOVED> > On Behalf Of
> Sumit Patel
> Sent: Monday, May 29, 2023 1:37 AM
> To: WebAIM Discussion List < <EMAIL 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
> >