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 Thursday, 29 November 2018 02:07:01 UTC