Skip to content

Instantly share code, notes, and snippets.

Rob Dodson robdodson

Block or report user

Report or block robdodson

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
@robdodson
robdodson / .eleventy.js
Last active Apr 18, 2019
Memoize an eleventy collection.
View .eleventy.js
const {memoize} = require('find-by-slug');
// Turn collection.all into a lookup table so we can use findBySlug
// to quickly find collection items without looping.
config.addCollection('memoized', function(collection) {
return memoize(collection.getAll());
});
View testing-screen-readers.txt
Skimmed this thread, so perhaps much of this was mentioned in some form or another before.
I would say testing against screen reader output is subject to all of the same issues that interactive ui testing suffers from.
It doesn't mean we shouldn't do it, but I have not seen it ever work in at least four instances I've seen it tried previously. The tests were always flakey, suffered from constant need for re-baselining, and generally were a net negative.
AOM is still under active development, so seems, at least for now, a poor target.
Chrome does indeed have an accessibility tree. We don't make it especially easy to introspect this tree. The easiest way currently is by using the chrome.automation extension api (which is only available on dev channel). It does have eventing and is what ChromeVox is based on.
Testing against this tree and making strong assertions against it for your given page makes the most sense to me.
View aom-example2.js
el.accessibleNode.describedBy =
new AccessibleNodeList([accessibleNode1, accessibleNode2]);
el.accessibleNode.activeDescendant = accessibleNode3;
View custom-listbox.html
<custom-listbox role="listbox"
aria-describedby="generated-id1 generated-id2"
aria-activedescendant="generated-id3">
View aom-example.js
// default role is "slider"
// set using private accessibleNode by the element author
<custom-slider id="mySlider">
// element consumer changes role to "button"
mySlider.accessibleNode.role = "button"
// element consumer nulls role
mySlider.accessibleNode.role = null
View custom-slider.js
class CustomSlider extends HTMLElement {
constructor() {
super();
this.accessibleNode.role = 'slider';
this.accessibleNode.valueMin = 0;
this.accessibleNode.valueMax = 5;
this.accessibleNode.valueNow = 3;
this.accessibleNode.valueText = 3;
}
}
View custom-slider.html
<custom-slider min="0" max="5" value="3" role="slider"
tabindex="0" aria-valuemin="0" aria-valuemax="5"
aria-valuenow="3" aria-valuetext="3"></custom-slider>
@robdodson
robdodson / readme.md
Created Sep 1, 2017
How to enable the experimental DevTools accessibility panel
View readme.md
  1. Go to chrome://flags/#enable-devtools-experiments and click 'Enable'. This will turn on the experiment in your version of Chrome.
  2. Restart Chrome.
  3. Open your DevTools and click the three vertical dots in the top right to open the context menu.
  4. Click on 'Settings'.
  5. Click on the 'Experiments' tab on the left hand side.
  6. Check the box next to 'Accessibility Inspection'.
  7. Close the DevTools, then reopen them.
  8. You're all set! Go inspect an element in the Elements panel and you should see a new 'Accessibility' tab over near the Style inspector.
View index.ejs
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Hello World</title>
<meta name="viewport" content="width=device-width, initial-scale=1">
</head>
<body>
<my-element></my-element>
View my-element.html
<!-- src/my-element.html -->
<link rel="import" href="../bower_components/polymer/polymer-element.html">
<dom-module id="my-element">
<template>
<h1>Hello, World! It's [[today]].</h1>
</template>
<script type=”module”>
// Heyyyy, we're pulling in a Node module!
You can’t perform that action at this time.