robdodson

We try to follow the cube.fyi methodology. The CSS for all component-like-things lives in the blocks directory. Blocks could either be BEM CSS components or web components. Here's a web component: https://github.com/GoogleChrome/developer.chrome.com/blob/main/site/_scss/blocks/_cookie-banner.scss

You can see how it's used here: https://github.com/GoogleChrome/developer.chrome.com/blob/0db454723269cc9ddcde1beb5789bf8760855665/site/_includes/partials/cookie-banner.njk#L3

We use an Eleventy transform to feed the HTML for every page to PurgeCSS. Our PurgeCSS config looks at the raw html, and also our JS files, to figure out which classes to include in the page. https://github.com/GoogleChrome/developer.chrome.com/blob/main/site/_transforms/purify-css.js

robdodson

<script type="text/javascript">
        
        /*
            Example cars.csv:
            
            Year,Make,Model,Length
            1997,Ford,E350,2.34
            2000,Mercury,Cougar,2.38

         */

robdodson

module.exports = function(eleventyConfig) {
  eleventyConfig.addFilter('debug', function(...args) {
    debugger;
  });
}

robdodson

var onload = function() {
    // If web components are supported this will fire immediately,
    // othewrise it will wait for the polyfills to load.
    // Load your components here
    var components = document.createElement('script');
    script.async = true;
    script.src = '../dist/page-sections.js';
    document.head.appendChild(components);
  };

robdodson

{ "keys": ["super+shift+o"], "command": "open_dir", "args": {"dir": "$file_path", "file": "$file_name"} }

robdodson

module.exports = (collection) => {
  return collection
    .slice(0, 3);
};

robdodson

require 'mechanize'

# Create a new instance of Mechanize and grab our page
agent = Mechanize.new
page = agent.get('http://robdodson.me/blog/archives/')

# Find all the links on the page that are contained within
# h1 tags.
post_links = page.links.find_all { |l| l.attributes.parent.name == 'h1' }

robdodson

/**
 * @license
 * Copyright (c) 2016 The Polymer Project Authors. All rights reserved.
 * This code may only be used under the BSD style license found at http://polymer.github.io/LICENSE.txt
 * The complete set of authors may be found at http://polymer.github.io/AUTHORS.txt
 * The complete set of contributors may be found at http://polymer.github.io/CONTRIBUTORS.txt
 * Code distributed by Google as part of the polymer project is also
 * subject to an additional IP rights grant found at http://polymer.github.io/PATENTS.txt
 */

robdodson

<!--
@license
Copyright (c) 2016 The Polymer Project Authors. All rights reserved.
This code may only be used under the BSD style license found at http://polymer.github.io/LICENSE.txt
The complete set of authors may be found at http://polymer.github.io/AUTHORS.txt
The complete set of contributors may be found at http://polymer.github.io/CONTRIBUTORS.txt
Code distributed by Google as part of the polymer project is also
subject to an additional IP rights grant found at http://polymer.github.io/PATENTS.txt
-->

robdodson

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.