Alexander Chudesnov Chudesnov

NOTE: This is no longer an experiment! You can use the accessibility inspector in Chrome Devtools now, including a fantastic color contrast inspection tool. Read more: https://developers.google.com/web/updates/2018/01/devtools#a11y

Just like any good element inspector helps you debug styles, accessibility inspection in the browser can help you debug HTML and ARIA exposed for assistive technologies such as screen readers. There's a similar tool in Safari (and reportedly one in Edge) but I like the Chrome one best.

As an internal Chrome experiment, this tool differs from the Accessibility Developer Tools extension in that it has privileged Accessibility API access and reports more information as a result. You can still use the audit feature in the Chrome Accessibility Developer Tools, or you could use the aXe Chrome extension. :)

To enable the accessibility inspector in Chrome stable:

Proposal for a lightning talk at the Reactive 2016.

Keep calm and like/retweet it on Twitter and star this Gist to vote on this talk.

Road from UndefinedLand

I work at Grammarly. We like React and happily use it in our applications. However, sometimes something goes wrong and bugs creep into the code. Here comes testing. It helps make us confident about the quality of our code.

Валидация: Эра Парсеров

Tchaikovsky

for JS - https://github.com/SimplePEG/Tchaikovsky-JavaScript
for Python - https://github.com/SimplePEG/Tchaikovsky-Python

SimplePEG

for JS - https://github.com/SimplePEG/JavaScript
for Python - https://github.com/SimplePEG/Python

	#!/bin/bash

	# Sync Homebrew installations between Macs via Dropbox
	#

	BREW="/usr/local/bin/brew"

	# first get local settings
	echo "Reading local settings ..."
	rm -f /tmp/brew-sync.*

	list=$(git branch --list \| grep -v \*)
	declare -a branches=($list)

	echo "Branches: "
	for i in "${!branches[@]}"; do
	printf "%s\t%s\n" "[$i]" "${branches[$i]}";
	done

	printf "Enter the number of the branch you'd like to switch to: "

	/**
	* Build for production:
	* $ NODE_ENV=production webpack
	*
	* Build for staging or development mode
	* $ webpack
	*
	* Run app server in dev mode and use Hot Module Replacement
	* $ NODE_ENV=webpack nodemon --watch ./app index.js
	*

	<div style="border:1px solid blue; margin: 5px; padding: 5px;">
	<label data-bind="text: labelText"></label>
	<input type="text" />
	</div>

	/**
	* = Visually Hide text
	*
	* Text remains accessible to AT such as Screen Readers
	* Updated version:
	* Taken from http://hugogiraudel.com/2016/10/13/css-hide-and-seek/
	*
	* ------------------------------------------------------------------------- */
	.visually-hidden {
	border: 0 !important;

	// UPDATE: In 2023, you should probably stop using this! The narrow version of Safari that
	// does not support `nomodule` is probably not being used anywhere. The code below is left
	// for posterity.

	/**
	* Safari 10.1 supports modules, but does not support the `nomodule` attribute - it will
	* load <script nomodule> anyway. This snippet solve this problem, but only for script
	* tags that load external code, e.g.: <script nomodule src="nomodule.js"></script>
	*
	* Again: this will not prevent inline script, e.g.:

	#!/usr/bin/env bash

	set -x
	shopt -s extglob dotglob

	cd "$HOME"
	rm -rf "$HOME/TEMP_DIR"
	mkdir "$HOME/TEMP_DIR"
	cd "$HOME/TEMP_DIR"
	git init