There is a lot that the add-on checks for and has been a great first check for accessibility issues. I did run into an issue where a properly marked up table within a form that contains columnheader roles (in th tags) which are assigned ids and the tbody contains a mixture of Spring Framework's form:input and form:textarea tags within the td tags. Each row has a td with the role of rowheader first, followed by td's with gridcell roles. Those visible form:input and form:textarea tags are all using aria-labelledby="rowheader_id columnheader_id".
The issue is that first the td tags containing the form:textarea and visible form:input tags all state that they are not labeled under 4.1 Compatible. The aria-labelledby tags were then copied to the td's which satisfied 4.1 Compatible but then of course was no longer satisfying 2.4 Navigable. From what I understand tds do not need to be labeled in that scenario. Please correct me if I am wrong. For this and a few other reasons, I would recommend checking with other accessibility checkers in addition to this one.
The best accessibility tool I have found so far. It saves a huge amount of time making what seems like an impossible task possible. It would be nice if it supported e10s though as it makes it a bit of a pain to use on the developer edition of firefox. Are there any plans to support e10s?
I do have a problem with the way the AI sidebar (and the FAE2 site too) evaluate ARIA roles. I don't think it is an AA violation if I don't use roles extensively all over the page. Or add roles to a widget and a special keyboard handler for this role if the widget is keyboard accessible without them. It is no violation either if a decorative image has only an alt="" attribute and no ROLE="PRESENTATION". This is optional. As I understood the ARIA elements: if I can solve something with pure HTML I should do so, if not I should use ARIA. So why it is a violation if my interface is accessible without ARIA all over the page? That's what the W3C tells us: "If you can use a native HTML element [HTML51] or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so."
So why I run into violation errors with your tool like "Add an ALT, ARIA-LABELLEDBY or ARIA-LABEL attribute to the IMG element to add a text alternative, or use ALT="", ROLE="PRESENTATION" or include the image as a CSS BACKGROUND-IMAGE to identify it as purely decorative." if there is an ALT=""??? So the scoring of your tool is for the birds - still I like to work with it.
AInspector Sidebar uses the OpenAjax Evaluation Library, which includes two user-selectable rulesets. Each ruleset includes at least one rule for each WCAG 2.0 Level A and AA requirement.
AInspector Sidebar can be configured to show both the primary WCAG 2.0 Success Criteria and the WCAG 2.0 compliance level (A or AA) as columns in the Rule Results table using the column picker widget in the upper right-hand corner of the table.
The OpenAjax Evaluation Library includes the following rulesets:
1. HTML5 and ARIA Techniques (default): based on the use of accessibility techniques available in the HTML5 and ARIA specifications . 2. HTML4 Legacy Techniques: based on the use of HTML4 and pre-ARIA accessibility techniques.
The user selects one of these two rulesets in the Preferences/Evaluation panel.
NOTE: I am the primary author of the OpenAjax Evaluation library
Thanks for your comments. While it might not be obvious from the rule results, choosing either of the two rulesets will cover WCAG 2.0 A and AA.
To see the coverage across all Rule Categories, in the Summary view select All Rules and then use the Rule Results column picker to show the 'Lev' column, which is the WCAG 2.0 Level. You can also sort by the 'Lev' column.
Please see the review by the OpenAjax Evaluation Library primary author.
AInspector was developed with user experience in mind.
The flow for using the tool is logical: High level understanding of Pass/Fail counts in a given page Drill down and review violations by sets such as Forms Understand individual violations using the rule definitions and element results Understand how to fix an issue using the Actions
The tool is based upon an open source rule set based upon WCAG 2.0 so there is no mystery in terms of what criteria are being applied to check pages.
If you don't like tools which light up an entire page with pass/fail icons, this tool might be for you because it allows you to inspect and highlight one issue at a time, e.g. light up all the elements with missing alt text and drill down to where it is using the code inspector.
The UI clearly identifies MC when manual checks are needed such as whether or not reading order is logical when CSS is disabled.
The aspects of AInspector that I like are include the ability to drill down from the Summary into the rule set categories such as Tables, Forms, and Keyboard Support.
The Actions are also extremely useful and prescriptive to show how to fix violations.
The color contrast checking is also very handy which does a top to bottom check on all foreground and background color combinations and provides a list of elements which do not meet the WCAG 2.0 AA minimum contrast ratios.
AInspector Sidebar is an excellent, easy-to-use tool for assessing the accessibility of a webpage or app. Running a scan is simple, and the results immediate. For those who are less familiar with accessibility practices, the results are easy to understand, and link back to more detailed explanations of specific guidelines.
The rulesets behind the application map to well-known WCAG 2.0 guidelines, making it easy to pursue conformance, but you can also select a more functional grouping that allows you to review accessibility issues by category.
AInspector Sidebar is also useful as a training tool, to help developers integrate accessibility features into their development practices. As developers proceed through their development cycle, they can run scans to better understand how their development choices impact the accessibility of their applications and make adjustments accordingly.
AInspector Sidebar is paired with the Functional Accessibility Evaluator version 2, an online tool that scans entire sites using the same criteria and rulesets. We have found this to be a valuable combination, as accessibility staff, developers, project managers, and others can capture the same accessibility information, ensuring better collaboration between those stakeholders.
We strongly urge our developers to use AInspector Sidebar to track the accessibility of their sites and applications.
I like using AInspector Sidebar. No need to copy the URL to another website. I just open AInspector and get immediate results for the page I’m viewing. When the sidebar opens, there’s a summary at the top that provides the number of violations, warnings, manual checks, and passes for the page. It makes it simple to quickly see how many accessibility challenges there are, and how severe they are.
To get more details, I look at the table that identifies the categories where the violations, warnings, and so on occurred. And I can dig down another level in detail by clicking on the category to see the individual rule results. When I select a rule that didn’t pass, AInspector even offers a suggested action to remedy the issue. This is a well-designed tool that provides a lot of helpful accessibility information.
The AInspector sidebar is the best of the in-browser automated tools for testing the accessibility of web pages and applications. The results are layed out in a clean and understandable design. The results are a summary of accessibility issues, organized by your choice of functional categories (e.g., headings, images, forms, and keyboard), or WCAG Guidelines (to take advantage of the abundant standards documents). Supporting documentation is well organized, providing summary analysis and links to the source documentation. And because of the attention to design and documentation, AInspector also excels as a teaching tool for development teams. Also, check out the great companion website testing tool, FAE 2.0.
AInspector can stand on its own. It has a very robust and community authored set of rules that it uses for determining accessibility. It is also one of the better tools available for checking the correctness of ARIA widget implementations. Not only does it look for proper ARIA widget structure and attributes + values, it also has a feature that allows the user to rerun the evaluation with a delay, so that a user can manually activate a control and check if a widget's roles, states, and properties are correctly maintained during use. Its integration with Firefox's DOM Inpsector makes it possible to "fix" errors (or just experiment) with the live page and rerun AInspector to come up with potential solutions. Very helpful.
But what really makes AInspector shine for me is its integration with FAE 2 (the free, enterprise spidering accessibility checker). An organization can use FAE 2 to spider an entire public facing web site and gather "global" issues. AInspector is then used to drill down to the detailed, code level on any one particular page.
AInspector and FAE use the same ruleset and reporting categorizations, so there is a one to one equivalence between the FAE global scans and the page level evaluations performed by AInspector.
More than just a basic add-on for occasional accessibility checks, AInspector is more properly thought of as key component in a site or enterprise-wide accessibility monitoring and analysis toolkit.
We are currently training staff to use it in conjunction with FAE at a major US university, where we plan on the AInspector + FAE combination as part of our overall web accessibility initiatives.
I use this tool quite often to give and overall assessment of accessibility issues. The tool provides a nice overview of issues and where they are located. It also specifies what items are violations, warnings, what items need manual checks and what items pass. The tool allows the user to dig in further to gather more information and details about why something is an issue, what the impact is, along with resource information as to how to re-mediate the issues. Overall a very useful add-on for web developers, and accessibility testers.
I'm using this tool daily since two years. I love it. It is very easy to install and use. The best part of the tool is it gives the summary of violations divided by rule category. It also maps the WCAG guideline that is being violated along with information of why/how it is violating the rule . User can further dig in by clicking on the element and it shows the related HTML code in the bottom part of the screen. User has option to select the ruleset (enable Aria techniques) of how the evaluation to be done. Overall this tool gives you good idea about the accessibility issues/warnings existing in the page.