RE: ARIA and Jaws question

One example of a shortcoming in Chrome is the <input type="file"> element. When using JAWS or NVDA (and perhaps other screen readers) it is not possible to tell if a file has been selected correctly or not (or if it was selected at all). I have tested all the possible means of navigation such as "arrowing", tabbing and shortcut keys. In every case, the screen reader announces the button but does not announce the filename (or the "No file chosen" message).

The other browsers are better, but by no means perfect. Firefox reads the filename when arrowing but not tabbing. Internet Explorer reads the filename when tabbing but not arrowing. The filename is not announced in either browser when using the shortcut key for buttons, but it is announced in Internet Explorer when the shortcut key for edit boxes is used.

Steve

-----Original Message-----
From: Steve Green 
Sent: 02 December 2018 14:50
To: w3c-wai-ig@w3.org
Subject: RE: ARIA and Jaws question

I can't think of any right now. They are usually things that are out of scope in my testing so I don't investigate or record them. I assume they are issues with the browser's accessibility tree or API because they are specific to Chrome.

To turn the question round, can you describe anything that Chrome does better than Internet Explorer or Firefox in relation to screen reader behaviour?

There may be some orthodoxy in people's thinking if they don't do any formal testing. But even those of us who do formal testing can only comment on the websites we have tested, so it's quite possible we will have different experiences from each other.

Steve

-----Original Message-----
From: Adam Cooper <cooperad@bigpond.com> 
Sent: 02 December 2018 00:13
To: Steve Green <steve.green@testpartners.co.uk>; w3c-wai-ig@w3.org
Subject: RE: ARIA and Jaws question

"My reasoning is that Chrome exhibits far more adverse behaviours than either Internet Explorer or Firefox"

Are you able to describe these 'adverse behaviours'? Are they about the browser or the screen reader?

As an everyday screen reader user, I find Internet Explorer 11 the most problematic followed by Firefox and then Chrome.

In my view, Firefox and Chrome work equally well with NVDA.

Just wondering how much of the thinking about the interoperability of browsers and screen readers is orthodoxy?

Cheers,
Adam 

-----Original Message-----
From: Steve Green [mailto:steve.green@testpartners.co.uk] 
Sent: Thursday, November 29, 2018 1:07 PM
To: w3c-wai-ig@w3.org
Subject: RE: ARIA and Jaws question

My reasoning is that Chrome exhibits far more adverse behaviours than either Internet Explorer or Firefox. Until recently, Chrome was not usable at all with JAWS, and they are still catching up. I cannot think of any occasion where it has performed better than the other browsers - it's either the same or worse.

I rarely experience any problems with Internet Explorer, but I only use JAWS for testing websites, not for everyday use. For the most part I find Internet Explorer works at least as well as Firefox, although it is lacking in support for some of the newer HTML elements and attributes.

I agree with you regarding the need for baked-in controls, with the caveat that browsers must allow them to be styled as designers wish. If that doesn't happen, and you can almost guarantee that Safari won't, the new controls won't be used. The same applies to existing elements - if you could style radio buttons, checkboxes and comboboxes any way you want, we wouldn't have all the terrible replacement techniques that most developers (and especially JavaScript framework developers) get wrong.

I have yet to see a complex widget implemented in an accessible manner. Some are theoretically accessible if you understand the interaction model, ensure your screen reader is in the correct mode and don't accidentally press the wrong key. I don't regard that as acceptable, but it's as good as it gets right now.

Steve

-----Original Message-----
From: Sean Murphy (seanmmur) <seanmmur@cisco.com> 
Sent: 29 November 2018 00:52
To: Steve Green <steve.green@testpartners.co.uk>; w3c-wai-ig@w3.org
Subject: RE: ARIA and Jaws question

Steve,

Interested in your reasoning why those Jaws users who are using Chrome are not doing themselves any favour. As a Jaws user, I avoid IE11 now due to stability issues and I am now finding strange behaviours when Jaws worked with a page with no modifications in the past and does not now. While Firefox works fine.

I use Firefox and Chrome, and do see different behaviour with Jaws and NVDA using the same web sites. This is why I come back to my prior post on another list where more controls like combo boxes, treeviews, etc must be baked into the browser and the HTML 5.2 standards. Saves a lot of hacks I see to make these complex widgets work.



Sean Murphy
SR ENGINEER.SOFTWARE ENGINEERING
seanmmur@cisco.com
Tel: +61 2 8446 7751

Cisco Systems, Inc.
The Forum 201 Pacific Highway
ST LEONARDS
2065
Australia
cisco.com

Think before you print.
This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
http://www.cisco.com/c/en/us/about/legal/terms-sale-software-license-agreement/company-registration-information.html

-----Original Message-----
From: Steve Green <steve.green@testpartners.co.uk> 
Sent: Thursday, 29 November 2018 12:57 AM
To: w3c-wai-ig@w3.org
Subject: RE: ARIA and Jaws question

I can't suggest how to fix this without seeing the code, but Chrome exhibits lots of incorrect behaviours that don't occur with Internet Explorer and Firefox. The last WebAIM screen reader survey showed that only 6.5% of screen reader users were using JAWS and Chrome, and frankly those people are not doing themselves any favours.

https://webaim.org/projects/screenreadersurvey7/#browsercombos


There are other gotchas with respect to non-editable textboxes. The last time I tested read-only fields, Dragon 15 (which is still the latest version) was able to edit them. A proposed workaround was to change the textboxes to "disabled", but that introduced new problems because they now don't receive focus. If a screen magnifier user is using keyboard navigation, it will skip right past the disabled textboxes and the user won't even know they are there. That's not always a problem but it was in our case because it was a timesheet application where the user needed to review and approve all the data even though they could not change it.

Steve Green
Managing Director
Test Partners Ltd


-----Original Message-----
From: Ginger Claassen <ginger.claassen@gmx.de> 
Sent: 28 November 2018 13:16
To: w3c-wai-ig@w3.org
Subject: ARIA and Jaws question

Good Morning everyone,


We currently have a web application here where some non editable text entry fields are correctly marked by ARIA but in Chrome they are not accesible by Jaws. However, in Internet Explorer they are accessible and visible to Jaws.

Is this due to some error in ARIA markup or is the Google Chrome Accessibility API not able to show those fields?

I would be glad about any idea how to fix this.


Thanks in advance for your input!


Solong


      Ginger

Received on Monday, 17 December 2018 04:43:24 UTC