busy or hidden - should they affect the audits?

[ricksbrown]

aria-busy

Soon I intend to add an audit along the lines of "MissingRequiredOwnedElement". In aria-toolkit this audit produced different messages depending on whether the element was 'aria-busy'. The spec says this:

"When a widget is missing required owned elements due to script execution or loading, authors MUST mark a containing element with aria-busy equal to true." http://www.w3.org/TR/wai-aria/roles#mustContain

This implies that it is OK (or not as bad) if the element does not contain required roles while it is busy.

While working on the 'NonExistentAriaRelatedElement' audit I wondered if we should be considering 'aria-busy' there too, although there is no specific mention in the spec. And perhaps other audits too, like checks for required states and properties?

Perhaps this is all not worthwhile for something that will rarely happen?

aria-hidden (or just hidden)

Far more likely to occur, how should hidden elements be handled? Should they really be treated the same as "visible" elements?

I was thinking maybe the severity should be reduced for hidden and/or busy elements?

[alice]

Regarding varying severity: the way it is now, we can't change the severity of a rule on a per-element basis: the result elements are collated in AuditRule.run() (https://github.com/GoogleChrome/accessibility-developer-tools/blob/master/src/js/AuditRule.js#L211) and the severity is applied to the rule result as a whole in Audit.run() (https://github.com/GoogleChrome/accessibility-developer-tools/blob/master/src/js/Audit.js#L256).

To some extent, this is due to the way results are presented in the extension (which this library spun off of).

Perhaps we could return two (or more) lists of elements from AuditRule.run() - one which is the current list of elements, and one (or more) which has/have a different/lower severity from the rest of the elements. Note, however, that we really only have two severity levels for failures: severe and warning (again, a result of the extension API) - info exists, but it's used in the extension to indicate a pass state, so we'd want to be careful using that as a failure state.

That also raises the question of how we'd modify Audit.run() to facilitate this - as you know, currently it returns a boolean indicating whether the element passes or fails the rule. If we were to have varying severities, we'd need a more sophisticated mechanism, while keeping the current API (as the extension doesn't use Audit.run(), it calls AuditRule.run() directly). Perhaps it could take an optional output parameter, or alternatively have Audit.run() call a secondary, optional, getSeverity() method on elements which fail the rule.

With all that as background... I think we should definitely exclude the element from the failure results (possibly adding it to the lower-severity results if they exist) if aria-busy is true, for the missing owned element case.

Regarding hidden elements; some rules ignore them (e.g. imagesWithoutAltText), others don't (e.g. badAriaRole). In general I've tried to go with the spirit of WCAG and ARIA and try to determine whether it's likely to actually cause issues (i.e. hiding images using aria-hidden is a reasonable technique for removing them from the accessibility tree, so we don't want to flag them, whereas something with a bad ARIA role which is hidden is probably going to be un-hidden at some point at which point it will obviously be a problem; the role is unlikely to change in the interim). So yes - I think hidden elements should go either in the 'less severe' bucket or just be ignored, in general, unless it's something which is likely to go unchanged when aria-hidden changes.

[ricksbrown]

Thanks for the detailed response Alice. I'll come back to this but putting it towards the bottom of the pile for now - I think bolstering the ARIA audits is more urgent. However if you would prefer me to look at this first let me know.

For now I am doing as you suggest and skipping elements that are aria-busy in missing owned element audit.

My gut feeling is that the return value of AuditRule.run() should perhaps change to a number similar to the concept of an exit status. It may even be largely backwards compatible since exit status 0 (success) is falsey and 1 (fail) is truthy.