E-mail List Archives

Search E-mail List Archives for

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

From: Kelly Ford
Date: Sun, Jun 03 2018 1:07PM
Subject: Wisconsin Jobs Site with JAWS or NVDA in IE and Chrome
No previous message | Next message →

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

From: Steve Faulkner
Date: Sun, Jun 03 2018 2:53PM
Subject: Re: Wisconsin Jobs Site with JAWS or NVDA in IE and Chrome
← Previous message | Next message →

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 ADDRESS 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
>
> > > > >

From: KellyFord
Date: Sun, Jun 03 2018 5:58PM
Subject: Re: Wisconsin Jobs Site with JAWS or NVDA in IE and Chrome
← Previous message | Next message →

Steve,

Thank you for the investigation. I had figured the problem was something as you discovered but was still going through to find the problematic code. Much appreciated for the time savings.

I have brought this problem to the attention of a contact listed on the page. Hopefully this gets investigated and corrected in a timely fashion.

Kelly

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Steve Faulkner
Sent: Sunday, June 3, 2018 3:53 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Wisconsin Jobs Site with JAWS or NVDA in IE and Chrome

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 ADDRESS 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
>
> > > archives at http://webaim.org/discussion/archives
> >

From: Marco Zehe
Date: Sun, Jun 03 2018 11:52PM
Subject: Re: Wisconsin Jobs Site with JAWS or NVDA in IE and Chrome
← Previous message | No next message

Hi Kelly and Steve,

I just threw this against Firefox with NVDA, and we do actually render the
page correctly. It isn't pretty, but thankfully, Firefox seems to handle
that illegal markup well. Maybe a browser to add back to your arsenal of
browsers to test (or use) sites with.

Marco


2018-06-04 1:58 GMT+02:00 KellyFord < = EMAIL ADDRESS REMOVED = >:

> Steve,
>
> Thank you for the investigation. I had figured the problem was something
> as you discovered but was still going through to find the problematic
> code. Much appreciated for the time savings.
>
> I have brought this problem to the attention of a contact listed on the
> page. Hopefully this gets investigated and corrected in a timely fashion.
>
> Kelly
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Steve Faulkner
> Sent: Sunday, June 3, 2018 3:53 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Wisconsin Jobs Site with JAWS or NVDA in IE and
> Chrome
>
> 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 ADDRESS 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
> >
> > > > > > archives at http://webaim.org/discussion/archives
> > > >
> > > at http://webaim.org/discussion/archives
> >
> > > > >