Coder Social home page Coder Social logo

googlechrome / accessibility-developer-tools Goto Github PK

View Code? Open in Web Editor NEW
2.3K 200.0 360.0 1.23 MB

This is a library of accessibility-related testing and utility code.

License: Apache License 2.0

JavaScript 94.17% XSLT 1.15% Python 0.57% HTML 2.78% CSS 0.87% CoffeeScript 0.46%

accessibility-developer-tools's Introduction

Build Status npm version npm downloads

Accessibility Developer Tools

This is a library of accessibility-related testing and utility code.

Its main component is the accessibility audit: a collection of audit rules checking for common accessibility problems, and an API for running these rules in an HTML page.

There is also a collection of accessibility-related utility code, including but not limited to:

Getting the code

To include just the javascript rules, require the following file:

https://raw.github.com/GoogleChrome/accessibility-developer-tools/stable/dist/js/axs_testing.js

git 1.6.5 or later:

% git clone --recursive https://github.com/GoogleChrome/accessibility-developer-tools.git

Before git 1.6.5:

% git clone https://github.com/GoogleChrome/accessibility-developer-tools.git
% cd accessibility-developer-tools
% git submodule init; git submodule update

Building

You will need node and grunt-cli to build.

  1. (Once only) Install Node.js and npm - useful instructions here: https://gist.github.com/isaacs/579814

    Make sure you have Node.js v 0.8 or higher.

  2. (Once only) Use npm to install grunt-cli

     % npm install -g grunt-cli  # May need to be run as root
    
  3. (Every time you make a fresh checkout) Install dependencies (including grunt) for this project (run from project root)

     % npm install
    
  4. (Rebuild if you make changes) Build using grunt (run from project root)

     % grunt
    

Troubleshooting

This project uses Closure Compiler to build our releases. You may need to install a recent version of JDK in order for builds to successfully complete.

Using the Audit API

Including the library

The simplest option is to include the generated axs_testing.js library on your page. After you build, you will have two versions of axs_testings.js:

  • Distribution Build: project-root/dist/js/axs_testing.js
  • Local Build (use if you make changes): project-root/tmp/build/axs_testing.js

Work is underway to include the library in WebDriver and other automated testing frameworks.

The axs.Audit.run() method

Once you have included axs_testing.js, you can call axs.Audit.run(). This returns an object in the following form:

{
  /** @type {axs.constants.AuditResult} */
  result,  // one of PASS, FAIL or NA

  /** @type {Array.<Element>} */
  elements,  // The elements which the rule fails on, if result == axs.constants.AuditResult.FAIL

  /** @type {axs.AuditRule} */
  rule  // The rule which this result is for.
}

Command Line Runner

The Accessibility Developer Tools project includes a command line runner for the audit. To use the runner, install phantomjs then run the following command from the project root directory.

$ phantomjs tools/runner/audit.js <url-or-filepath>

The runner will load the specified file or URL in a headless browser, inject axs_testing.js, run the audit and output the report text.

Run audit from Selenium WebDriver (Scala):

 val driver = org.openqa.selenium.firefox.FirefoxDriver //use driver of your choice
 val jse = driver.asInstanceOf[JavascriptExecutor]
 jse.executeScript(scala.io.Source.fromURL("https://raw.githubusercontent.com/GoogleChrome/" +
   "accessibility-developer-tools/stable/dist/js/axs_testing.js").mkString)
 val report = jse.executeScript("var results = axs.Audit.run();return axs.Audit.createReport(results);")
 println(report)

Run audit from Selenium WebDriver (Scala)(with caching):

 val cache = collection.mutable.Map[String, String]()
 val driver = org.openqa.selenium.firefox.FirefoxDriver //use driver of your choice
 val jse = driver.asInstanceOf[JavascriptExecutor]
 def getUrlSource(arg: String): String = cache get arg match {
    case Some(result) => result
    case None =>
      val result: String = scala.io.Source.fromURL(arg).mkString
      cache(arg) = result
      result
  }
 jse.executeScript(getUrlSource("https://raw.githubusercontent.com/GoogleChrome/" +
   "accessibility-developer-tools/stable/dist/js/axs_testing.js"))
 val report = js.executeScript("var results = axs.Audit.run();return axs.Audit.createReport(results);")
 println(report)

If println() outputs nothing, check if you need to set DesiredCapabilities for your WebDriver (such as loggingPrefs): https://code.google.com/p/selenium/wiki/DesiredCapabilities

Using the results

Interpreting the result

The result may be one of three constants:

  • axs.constants.AuditResult.PASS - This implies that there were elements on the page that may potentially have failed this audit rule, but they passed. Congratulations!
  • axs.constants.AuditResult.NA - This implies that there were no elements on the page that may potentially have failed this audit rule. For example, an audit rule that checks video elements for subtitles would return this result if there were no video elements on the page.
  • axs.constants.AuditResult.FAIL - This implies that there were elements on the page that did not pass this audit rule. This is the only result you will probably be interested in.

Creating a useful error message

The static, global axs.Audit.createReport(results, opt_url) may be used to create an error message using the return value of axs.Audit.run(). This will look like the following:

*** Begin accessibility audit results ***
An accessibility audit found 4 errors and 4 warnings on this page.
For more information, please see https://github.com/GoogleChrome/accessibility-developer-tools/wiki/Audit-Rules

Error: badAriaAttributeValue (AX_ARIA_04) failed on the following elements (1 - 3 of 3):
DIV:nth-of-type(3) > INPUT
DIV:nth-of-type(5) > INPUT
#aria-invalid

Error: badAriaRole (AX_ARIA_01) failed on the following element:
DIV:nth-of-type(11) > SPAN

Error: controlsWithoutLabel (AX_TEXT_01) failed on the following elements (1 - 3 of 3):
DIV > INPUT
DIV:nth-of-type(12) > DIV:nth-of-type(3) > INPUT
LABEL > INPUT

Error: requiredAriaAttributeMissing (AX_ARIA_03) failed on the following element:
DIV:nth-of-type(13) > DIV:nth-of-type(11) > DIV

Warning: focusableElementNotVisibleAndNotAriaHidden (AX_FOCUS_01) failed on the following element:
#notariahidden

Warning: imagesWithoutAltText (AX_TEXT_02) failed on the following elements (1 - 2 of 2):
#deceptive-img
DIV:nth-of-type(13) > IMG

Warning: lowContrastElements (AX_COLOR_01) failed on the following elements (1 - 2 of 2):
DIV:nth-of-type(13) > DIV
DIV:nth-of-type(13) > DIV:nth-of-type(3)

Warning: nonExistentAriaLabelledbyElement (AX_ARIA_02) failed on the following elements (1 - 2 of 2):
DIV:nth-of-type(3) > INPUT
DIV:nth-of-type(5) > INPUT
*** End accessibility audit results ***

Each rule will have at most five elements listed as failures, in the form of a unique query selector for each element.

Configuring the Audit

If you wish to fine-tune the audit, you can create an axs.AuditConfiguration object, with the following options:

Ignore parts of the page for a particular audit rule

For example, say you have a separate high-contrast version of your page, and there is a CSS rule which causes certain elements (with class pretty) on the page to be low-contrast for stylistic reasons. Running the audit unmodified produces results something like

Warning: lowContrastElements (AX_COLOR_01) failed on the following elements (1 - 5 of 15):
...

You can modify the audit to ignore the elements which are known and intended to have low contrast like this:

var configuration = new axs.AuditConfiguration();
configuration.ignoreSelectors('lowContrastElements', '.pretty');
axs.Audit.run(configuration);

The AuditConfiguration.ignoreSelectors() method takes a rule name, which you can find in the audit report, and a query selector string representing the parts of the page to be ignored for that audit rule. Multiple calls to ignoreSelectors() can be made for each audit rule, if multiple selectors need to be ignored.

Restrict the scope of the entire audit to a subsection of the page

You may have a part of the page which varies while other parts of the page stay constant, like a content area vs. a toolbar. In this case, running the audit on the entire page may give you spurious results in the part of the page which doesn't vary, which may drown out regressions in the main part of the page.

You can set a scope on the AuditConfiguration object like this:

var configuration = new axs.AuditConfiguration();
configuration.scope = document.querySelector('main');  // or however you wish to choose your scope element
axs.Audit.run(configuration);

You may also specify a configuration payload while instantiating the axs.AuditConfiguration, which allows you to provide multiple configuration options at once.

var configuration = new axs.AuditConfiguration({
  auditRulesToRun: ['badAriaRole'],
  scope: document.querySelector('main'),
  maxResults: 5
});

axs.Audit.run(configuration);

License

Copyright 2013 Google Inc. All Rights Reserved.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

accessibility-developer-tools's People

Contributors

addyosmani avatar bicknellr avatar ckundo avatar davidhsv avatar garcialo avatar jaimeiniesta avatar jdan avatar joscha avatar loginx avatar mikewest avatar minorninth avatar philschatz avatar rachelshe avatar ricksbrown avatar seankilleen avatar tiagojustino avatar valdrinkoshi avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

accessibility-developer-tools's Issues

Also validate scope if it's a DOM node

In the rules, querySelectorAll is used, but that only selects descendants, not root element as well. I think we should validate the root element too, if it's a DOM node (not the document of course).

Test suite setup needs cleanup

  • running make test outputs file contents to the console
  • file naming conventions for QUnit tests are not used
  • Makefile is outdated
  • The test run should open the browser

We've got an incoming set of pull requests to resolve these issues.

Missing <img> alt attribute should be an error, not a warning.

WebAIM indicates that even presentational images should have alt attributes, they should just be empty as an instruction to assistive tech to ignore them. Otherwise screen readers may read the file name or apply other heuristics to guess the description.

What do you think about elevating the severity on this audit to an error rather than a warning?

Here is the line: https://github.com/GoogleChrome/accessibility-developer-tools/blob/master/src/audits/ImageWithoutAltText.js#L27

ReferenceError: axs is not defined

In my local dev environment and on preview servers locked by .htaccess I constantly receive errors in chrome devtools saying axs is not defined.

Uncaught ReferenceError: axs is not defined constants.js:1
Uncaught ReferenceError: axs is not defined utils.js:1
Uncaught ReferenceError: axs is not defined audits.js:1
Uncaught ReferenceError: axs is not defined extension_properties.js:1
Uncaught ReferenceError: axs is not defined extension_audits.js:1

duplicate and/or invalid ID checks

Another audit I would like to port from aria-toolkit, HOWEVER I wanted to check with the team first.

The primary purpose of this audit is to ensure that IDs are unique in the DOM.
I also had a check for invalid IDs (which in HTML5 simply means no whitespace).

The reason I ask about this one is because it is not strictly speaking an accessibility audit - it is more of an HTML validation task.

I felt the duplicate ID check in particular was essential to ARIA (because of IDREFs) and therefore worthy of being part of accessibility tools.

Should I add ID audits?

busy or hidden - should they affect the audits?

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?

Allow configuration of severity levels

Suggested API:

var auditConfig = new axs.AuditConfiguration();
auditConfig.setSeverity('imgWithoutAltText', axs.constants.Severity.SEVERE);

This would allow developers who have different priorities to determine the severity levels of the various rules themselves; for example, allowing the 'imgWithoutAltText' to be an error rather than a warning as per issue #10.

Incorrect use of nth-of-type against className in utils.getQuerySelectorText

nth-of-type does not correlate to the selector to its left, but the nodeName of the node. getQuerySelectorText incorrectly tests against classNames and appends nth-of-type if it finds siblings with the same classes. This can cause it to generate some invalid selectors.

I've put together a test page where this in a problem:
https://gist.github.com/dsturley/77cc547ad95ced341dbe

It takes a node, passes it to getQuerySelectorText and then attempts to re-select with that selector, which fails.

AX_FOCUS_01 Possible false positive on Floated images in Anchor elements?

When images are floated (for left or right positioning) within an anchor element. The <a> element size is officially 0px (for both width and height). However I am not sure that it should report any warning in this case, as long as the anchor contains a visible image with an alt text. The image being in fact nor invisible nor obscured regardless of the wrapping anchor size.

The only way to get around the warning is to make the image an inline-block (which could create left and right alignment hurdles), or assign the float at the anchor level.

Although traditionally the float is placed on the <img> because it may or may not have a wrapping anchor around it.

But technically, I don't think a screen reader or a keyboard user is impacted by the 0px size of the anchor. In which case, it's probably only worth presenting a Warning only if the image does not contain an alt text, or if the image is actually and verifiably hidden.

Make sure labels are non-empty

In practice it's possible to get into a situation where you have:

<input placeholder>

In my case a third-party lib was adding an empty placeholder to my <input> fields.

Right now we're not erroring in these cases because we just check for presence of the placeholder attribute or <label> parent. We should assert non-emptiness as well.

You can imagine this happening with <label>s too:

<label><input></label>

Yes, there's a <label> parent, but there's functionally no label. That's bad.

For <img alt=""> I think it's a little different as the recommendation for presentation-only images is to use an empty alt, right? Does the same recommendation exist with empty placeholders and <label>s with no text content?

Should warn on focusable with no role

If an author creates an item on the page that's focusable by adding tabindex=0, and it's not already a form control, it should have a role - and specifically it should have a "widget" role like button or checkbox or one of the "composite control" roles grid, griditem, listbox, or option.

This should probably be an Error and not a warning if we're sure it has a click handler - because JAWS and NVDA will not make an Enter or Space trigger a mouse click if you focus on that item.

If we don't know if it has a click handler, it could be a warning. Probably better to have a role, but if it's not really a widget that has an action, then it won't affect anything.

Dependency failure when running tests - Closure Compiler compiler.jar

We wanted to run the tests in the browser, and expected that running $ make test would generate the appropriate dependencies. Instead we got:

Unable to access jarfile /Users/pivotal/src/closure/compiler.jar
make: *** [js] Error 1

We fixed the failure by downloading closure compiler and moving compiler.jar to the correct location.

I suspect a maven manifest would be a better solution.

Repost from https://code.google.com/p/accessibility-developer-tools/issues/detail?id=10

InternalError: too much recursion

Running the audit against some pages throws 'too much recursion' error with the following stack trace in our integration tests:

Selenium::WebDriver::Error::JavascriptError:
  too much recursion
# [remote server] http://127.0.0.1:49157/...:in `axs.properties.findTextAlternatives'
# [remote server] http://127.0.0.1:49157/...:in `axs.properties.getTextFromDescendantContent'
# [remote server] http://127.0.0.1:49157/...:in `axs.properties.findTextAlternatives'
# [remote server] http://127.0.0.1:49157/...:in `axs.properties.getTextFromHostLangaugeAttributes'
# [remote server] http://127.0.0.1:49157/...:in `axs.properties.findTextAlternatives'
# [remote server] http://127.0.0.1:49157/...:in `axs.properties.getTextFromDescendantContent'
# [remote server] http://127.0.0.1:49157/...:in `axs.properties.findTextAlternatives'
# [remote server] http://127.0.0.1:49157/...:in `axs.properties.getTextFromHostLangaugeAttributes'
# [remote server] http://127.0.0.1:49157/...:in `axs.properties.findTextAlternatives'
# [remote server] http://127.0.0.1:49157/...:in `axs.properties.getTextFromDescendantContent'
# [remote server] http://127.0.0.1:49157/...:in `axs.properties.findTextAlternatives'
# [remote server] http://127.0.0.1:49157/...:in `axs.properties.getTextFromHostLangaugeAttributes'
# [remote server] http://127.0.0.1:49157/...:in `axs.properties.findTextAlternatives'
# [remote server] http://127.0.0.1:49157/...:in `axs.properties.getTextFromDescendantContent'
# [remote server] http://127.0.0.1:49157/...:in `axs.properties.findTextAlternatives'
# [remote server] http://127.0.0.1:49157/...:in `axs.properties.getTextFromHostLangaugeAttributes'
.....

I'm trying to debug the issue, but let me know if anything's apparent to you.

-Nishit

TypeError: 'undefined' is not an object (evaluating 'a[0].textContent')

When I run the audit in a phantomjs runner on github.com and pivotallabs.com I get the following. This is a recent regression. I'll dig deeper but documenting it here for now.

TypeError: 'undefined' is not an object (evaluating 'a[0].textContent')

../../google-chrome/accessibility-developer-tools/gen/axs_testing.js:1535
../../google-chrome/accessibility-developer-tools/gen/axs_testing.js:1292
../../google-chrome/accessibility-developer-tools/gen/axs_testing.js:1383
phantomjs://webpage.evaluate():2
phantomjs://webpage.evaluate():4
phantomjs://webpage.evaluate():4
null

Provide more context for audit failures

For example, for color contrast failures, provide the same information that's provided in the Accessibility sidebar in the Accessibility Developer Tools extension (calculated contrast radio, bgColor, fgColor, suggested color pairs for each target contrast ratio value).

Provide toBeAccessible matcher for Jasmine tests

Again, sorry about not being able to submit a proper pull request right now, but here's the code snippet I'm using to make accessibility testing stupid-easy in a Jasmine environment:

goog.provide('axs.testing.matchers');

/**
 * A custom matcher that checks whether the element and all descendants pass
 * a suite of accessibility checks.
 *
 * Example:
 *
 *   expect(element).toBeAccessible();
 *
 *
 * @this {*}
 * @return {boolean}
 */
axs.testing.matchers.toBeAccessible = function() {
  var auditConfig = new axs.AuditConfiguration();
  auditConfig.scope = this.actual;

  var results = axs.Audit.run(auditConfig);
  var auditResults = axs.Audit.auditResults(results);

  if (!this.isNot) {
    this.message = auditResults.toString.bind(auditResults);
  }

  return auditResults.numErrors() == 0;
};


// Register the matchers globally if we're in a Jasmine environment
if (jasmine && beforeEach) {
  beforeEach(function() {
    this.addMatchers({
      toBeAccessible: axs.testing.matchers.toBeAccessible
    });
  });
}

AX_COLOR_01: Contrast issue on gradient backgrounds

Running the audit on: https://portal.contact-associates.co.uk/

It fails for a colour contrast issue... white text on a gradient background.

Looking at the "Home" link as an example (main nav), the inspector shows:

Contrast ratio: 1.00 
AA level (4.54): #767676/#ffffff 
AAA level (7.00): #595959/#ffffff 

Not sure where its getting the "1.00", or what the 2 grey colours (#767676 or #595959) are for.

But it should be comparing white against something along the gradient range of #9E4594 (5.6) or #761786 (9.4) - personally I would compare against all colours and report on the worst contrast, but I realise that can get difficult the more colours you have on the gradient.

For reference I am now setting the background directly on the <a> to test, as before it was just on the parent <ul>... and just setting a static background colour (which is still there for the older browsers) does resolve this issue.

How to add new Audit Rules!

I've been planning to add new audit rules to the accessibility developer tools. How easy/difficult is it going to be? I have forked this project. Should I go ahead with simply adding a new .js file to src/sudits? Will that work?
Thanks!

AX_TEXT_01 Accessibility Audit test should probably ignore role=presentation elements

Reported by [email protected] on Chromium issue tracker: https://code.google.com/p/chromium/issues/detail?id=398482

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36

Steps to reproduce the problem:

  1. Run the Accessibility audit on a page containing an element with an ARIA role of presentation
  2. The AX_TEXT_01 test fails.

What is the expected behavior?

What went wrong?
I think that the test should have passed. According to http://www.w3.org/TR/wai-aria/roles#presentation, elements with this role should not be mapped to the accessibility API. I might be misreading the spec, but I think this means that elements containing that role should not need a label.

Did this work before? No

Color contrast audit behaves differently in Windows Chrome than in Mac

Around 3:25 in the Accessibility Developer Tools video: https://www.youtube.com/watch?v=SHTC9IApgbw&feature=youtu.be the tool shows an accessibility warning with the contrast ratio and recommends new colors with higher contrast. The demo appears to be running on some sort of Evil operating system, if I recall my Latin properly.
When I try this in the latest version of Chrome on Windows 7, however, there is no such information to be found. Is this hiding somewhere? Or does the audit behave differently on different platforms?

from https://groups.google.com/d/msg/introduction-to-web-accessibility/VQo-XTeMHpU/hBfccNP3GWMJ

AX_FOCUS_01 Shouldn't anchor elements visible onFocus be excluded from this warning.

It's me again with another link focus related conundrum:

Sites get the warning "These elements are focusable but either invisible or obscured by another element" on <a> elements such as skip links or menubar links, even if those focusable elements are actually shown via specific CSS a:focus rules.

Shouldn't you check the onFocus visibility of such elements dynamically first, before considering it invisible or obscured?

If the element is purposely shown with a:focus, it is technically visible by a keyboard user using the tab key, as well as a mouse user. Properly designed navigation bars with pull down submenus made visible onFocus is a good use case here.

It would also help developers determining which links are not visible by sightseeing users vs those which are purposely shown to both via a:focus rules, and assess whether the ones receiving a warning shall be tagged as aria-hidden or not.

PS: As added enforcement to verify that those links are in fact shown, you could perhaps check the contrast ratio while onFocus. If the contrast ratio fail in both states, report it as insufficiently visible or something like that?

axs.utils.elementIsOutsideScrollArea is wrong when there are absolute positioned elements positioned outside of the body element

Example snippet (but note that tab contents should be long enough to scroll off the screen):

<body>
<div style="position: absolute; left: 0px; top: 0px; width: 1438px; height: 32px;">
  <span>Title bar</span>
</div>

<div id="main-contents">
  <div style="display: none; position: absolute; left: 0px; top: 32px; width: 1438px; height: 358px;">
    Tab 1 (hidden)
  </div>
  <div style="position: absolute; left: 0px; top: 32px; width: 1438px; height: 358px;">
    Tab 2 (shown)
  </div>
  <div style="display: none; position: absolute; left: 0px; top: 32px; width: 1438px; height: 358px;">
    Tab 3 (hidden)
 </div>
</div>
</body>

This will cause document.body.scrollHeight to be less than the height of all content, and thus the logic in axs.utils.elementIsOutsideScrollArea will incorrectly detect elements as being outside the scroll area when they are not.

Expand the list of unclear labels

We currently check for "click here". Other common stopwords I see are:

  • OK, Yes, Confirm -- generic dialog buttons can usually be more descriptive.
  • here - including "tap here", "go here", etc.
  • more - including "learn more", "read more", etc.
  • next - including "next page", etc.

Add warning that AX_FOCUS_02 is not available from axs.Audit.run()

I compared the Chrome plugin with my results from running axs.Audit.run() and kept noticing that the warning AX_FOCUS_02 was being included in the plugin but not from axs.Audit.run().

After digging in the source I realized it is because this rule requires the "console API" as it uses getEventListeners(), which is not available in the DOM (i.e. outside of Firebug, Chrome DevTools, etc.). http://stackoverflow.com/questions/9046741/get-event-listeners-attached-to-node-using-addeventlistener

Would it make sense to add a warning about this in the documentation under "The axs.Audit.run() method"? Are there others who might get tripped up by this?

Provide assertAccessible(element) for closure unit tests

I apologize for not having the time to submit a proper pull request, but I wanted to get this recorded because it's pretty straightforward and I'd like other projects to be able to take advantage of this:

/**
 * Asserts that the given element and its descendants pass a suite of
 * accessibility checks.
 *
 * @param {!Element} element
 */
function assertAccessible(element) {  
  var auditConfig = new axs.AuditConfiguration();
  auditConfig.scope = element;

  var results = axs.Audit.run(auditConfig);
  var auditResults = axs.Audit.auditResults(results);

  assert(auditResults.toString(), auditResults.numErrors() == 0);
}

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.