googlechrome / accessibility-developer-tools Goto Github PK

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);
}

Product owners, especially those with a Section 508 compliance criteria, need to have a mapping between the rules and W3C standards. README might be the right place to start.

The tests are failing on master, we've got a fix coming up.

This is specified here: http://www.w3.org/TR/html-aapi/#accessible-name-and-description-calculation

some elements say "use the * element subtree" in the accessible name calculation formula, others do not.

For example, 4.48 should be acceptable for WCAG's recommendation of 4.5 for normal text.

Repro: run audit on https://groups.google.com/forum/#!overview; several failures of the controls without labels rule on elements with role=presentation.

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

We defined a backfill method, matchesSelector, but failed to implement it globally and it is causing errors in Firefox.

Writing a test and fix now.

are these useful anymore? If not, let's delete them.

• frames
• release
• color
• ignore
• library
• computed-text

https://github.com/GoogleChrome/accessibility-developer-tools/branches

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!

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

Screen readers will skip elements without any text content, so we should not include non-tab-focusable elements with an empty computed text content in relevant elements for this rule.

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?

Here is a grunt library to do this:

https://github.com/gruntjs/grunt-contrib-qunit

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).

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

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

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.

The diff on the branch is creating confusion with mirrors, per issue #46

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?

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.

Right now the package.json says 2.6. The git tags should reflect the version we have in package.json. Also, I suggest we use the semver pattern for version numbers. [major].[minor].[patch]-[pre] - http://semver.org/

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.

create a grunt task to make releases easier (see #39)

This will allow us to avoid the git submodule confusion: There's an npm package already that we can use: https://npmjs.org/package/closure-library

Separating the failure message content from the auditing and reporting logic will make it easier to support multiple languages and message types.

@ckundo & @tjohn

Placeholder text should meet contrast requirements as well as body text.

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?

In particular, define guidelines around unit and integration testing.

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.

Right now when checking if an element is visible we are only checking opacity, bounding box, and positioning. We check for display: none and visibility: hidden if it is relevant.

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

An input like <input type="text" placeholder="I have no label!"> passes the label audit, but has no proper label.

See http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-placeholder-attribute

See https://github.com/ckundo/access-lint

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.

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
    });
  });
}

Should probably:

• Lint
• Compile
• Run tests

Warn when a focusable element has CSS specifying outline:none or outline:0.

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

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

Keeping axs_testing.js tracked is making the commit history difficult to read, and it has also been getting out of sync.

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).

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?

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.

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?

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.

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

A developer using the tools should be able to include the javascript rules without including and compiling the entire project. We may want to investigate a packaging tool like http://bower.io/ to package generated js rules.

See also https://github.com/Casecommons/capybara-accessible/pull/5