Comments (2)
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.
from accessibility-developer-tools.
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.
from accessibility-developer-tools.
Related Issues (20)
- Export results to Checkstyle
- Project status HOT 2
- Unable to generate accessibility reports for dynamic web pages HOT 2
- v2.12.0 doesn't contain all tests
- Too many tabs. Doing too much. HOT 1
- Wi-Fi v's Bluetooth HOT 2
- Is accessibility-developer-tools being replaced by Google lighthouse?
- Link With Unclear Purpose fails even when aria-label is defined
- TypeError: null is not an object (evaluating 'axs.utils.getRoles(a).valid')
- All links to WAI-ARIA specs broken in README and Wiki HOT 3
- AX_ARIA_08 triggers on <tr>
- Authentication issue
- Hack game
- Add `aria-current` to the list of valid attributes
- AX_HTML_03 missing from Audit Rules documentation
- Developer tools chrome HOT 1
- Missing role="switch" validation HOT 1
- Code
- aria-haspopup does not include all possible values HOT 1
- make it easier
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from accessibility-developer-tools.