6.0.2 Chrome Accessibility Audit - This element has an unsupported ARIA attribute

[tjstuart]

Hello

I recently ran our app through the Accessibility Audit available in Chrome.

I would like some clarification on below and also any comments on how much importance one places on audits of [Severe] level such as this one.

On a screen/form with a bunch of various input fields like date, text, checkbox etc. the audit will whinge ...

[Severe] This element has an unsupported ARIA attribute
See https://github.com/GoogleChrome/acce...les#ax_aria_10

Taking a date field as an example of one of the elements (which has a ARIA role of "combobox"), and doing a little digging, the specific ARIA attribute it is referring to in the case of "combobox" is aria-readonly, which apparently is not applicable to role "combobox" - https://www.w3.org/TR/wai-aria/state...#aria-readonly.

Is this really an issue which should be considered severe? I guess Ext should not really be adding that attribute. Anyone know the ramifications to screen readers and the like if these unsupported attributes are present?

There are a bunch of other test failing with [Severe] level, for example "ARIA attributes which refer to other elements by ID should refer to elements which exist in the DOM", which, in a dynamic app where child menus have not yet rendered, would occur often.

Any advice?

[tjstuart]

Anyone?

[Kevin Jackson]

Best support for Aria will be using the Aria theme. With each version, we have made improvements in ARIA support.

The engineers working on Aria gave the following advice.

For best results with screen readers, you would need to use Ext JS 6.2; we target Firefox with JAWS and NVDA screen reader

http://examples.sencha.com/extjs/6.2.0/examples/classic/aria/



Kevin Jackson
Sencha Support Team

[tjstuart]

Thanks for reply.

I am aware of the ARIA theme and the recommended FF/NVDA target. I'm really asking about the supposedly Severe warnings thrown in an accessibility audit.

Are you suggesting that, for example, the ARIA theme does not include unsupported ARIA attributes in DOM Elements? I doubt the ARIA theme addresses this.

For example, see http://examples.sencha.com/extjs/6.2...tml?theme=aria . Not only does this not render properly at all (in at least Chrome), it fails many accessibility audits.

As my original post suggests, I would appreciate some considered commentary.


... later edit, I found http://examples.sencha.com/extjs/6.2.../classic/aria/ which renders properly, but still failing same audits. I'm not suggesting that ExtJS should be passing 100% with accessibility as much is up to the application itself, just want clarification on those specific Severe warnings. You can run the accessibility audit on http://examples.sencha.com/extjs/6.2.../classic/aria/ and you will see what I am on about.

[Kevin Jackson]

I've entered the theme link as a bug. DOCS-334. I may be incorrect but it may be very difficult to do the Aria theme in the Theme Viewer, since it is making choices not in a standard theme. As you saw, the Accessibility demo does render correctly but is still not fully compliant. We are aware of that and continue to move in that direction but I believe we are aware there is more work to do. I have asked the engineering team for more clarification but at present, that is all I have.


Kevin Jackson
Sencha Support Team

[nohuhu]

tjstuart,

Our primary goal is to make accessible things work with AT available today; emitting strictly HTML/ARIA compliant HTML is not a priority at the moment. Things like unsupported ARIA attributes do happen, and in real life they should not cause much trouble if any at all.

Not sure why Google team decided to mark things like that as severe problems, I've never heard of a screen reader misbehaving because of combobox widget having aria-readonly attribute.

[tjstuart]

Thanks Kevin and nohuhu.

[tjstuart]

Perhaps we can move this thread to the new Accessibility forum? I believe there is some useful info in this thread. No big deal if not.

[nohuhu]

@tjstuart,

Good idea, done and done.