WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Wisconsin Jobs Site with JAWS or NVDA in IE and Chrome

for

From: Steve Faulkner
Date: Jun 3, 2018 2:53PM

Hi Kelly, first off this page is one hot mess of very poor code, looks like
it was saved from a word document :-(
Given that the issue only occurs in chrome, but does occur with both JAWS
and NVDA, suggested to me that it has something to do with how the
accessibility tree is being exposed in chrome.

I created a test case <https://s.codepen.io/stevef/debug/wXMgqd> copying a
subset of the code from the page. I could reproduce the issue in chrome Version
67.0.3396.62 (Official Build) (64-bit) and latest JAWS 2018 and latest
NVDA.

What I found was that the screen readers would only announce the first
paragraph.

Looking at the code i attempted to debug the issue by commenting out bits
of the code. I noted there were 2 nested spans that were wrapped around the
rest of the content, I commented out the span start tags and voila the rest
of the content was announced by both screen readers in chrome. Test case
with span tags commented out <https://s.codepen.io/stevef/debug/KeVazy>

So it seems like this is an example where the correct parsing of the
document to produce a usable accessibility tree, in chrome, breaks due to
non conforming nesting of elements.



--

Regards

SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;

On 3 June 2018 at 20:07, Kelly Ford < <EMAIL REMOVED> > wrote:

> Hi,
>
>
>
> From time to time I'll notice differences in how different screen readers
> present web pages in the various browsers. That's not overly surprising.
> Today, however, I had probably the most striking difference I've personally
> ever encountered when looking up something for a friend on a Wisconsin jobs
> web site.
>
>
>
> The site is at http://wisc.jobs.
>
>
>
> In Chrome, using both JAWS and NVDA, a big and probably most important part
> of the web page was missing from what the screen readers presented.
> Namely,
> the entire search feature.
>
>
>
> In Internet Explorer both screen readers presented a table with the
> different input fields for conducting a job search. This was not available
> at all in Chrome with the default experience of either screen reader.
>
>
>
> In Chrome, if I turned off the screen reader web reading mode (Virtual PC
> in
> JAWS and Browse mode in NVDA) and tabbed through the page, I did get to
> what
> I believe was the search feature. Both screen readers encountered several
> silent tab stops. The number of these was equivalent to the number of
> input
> fields I was able to find in IE. The fact that these tab stops were
> completely silent in both screen readers was an interesting wrinkle. If an
> edit box or other control is missing a label, I'd still expect to hear
> "edit" and such.
>
>
>
> Also, if I had the web reading mode off and asked Chrome to Inspect the
> current element on the different silent tab stops, the element tree opened
> to different input fields, which also leads me to believe the search
> controls are present in Chrome in general.
>
>
>
> I'm curious if this difference repros for anyone else. I've tried on a
> couple machines. Also, any theories on what could contribute to this? I'm
> still hunting through the page source and am curious if others have
> encountered a situation like this on other sites?
>
>
>
> For what it is worth, in Firefox and Edge, both screen readers and Narrator
> also present the search fields.
>
>
>
> Kelly
>
> > > > >