voorhoede / a11y-viewer Goto Github PK

Currently the a11y-viewer only works in "JS capable" browsers. The viewer could work perfectly fine without JS if we add a server. Instead of using JS on input change, we could make the entire form submittable to a server. The server would read the query parameters (from #3 and #18) and render the viewer with the appropriate filters set. Instead of using GitHub Pages we could use Heroku to host the a11y-viewer so we can also deploy the server.

Now we write everything in one js file. Shall we split it up into components?

Create separate build tasks for development and production, so that minification of css/html/js is turned off in development. Console.logs/debuggers now get stripped.

The placeholder variable has been replaced after the initial build, so the build:css/build:js task cannot replace the inline content. Solution could be to rebuild html/css/js all together.

I'd like this project to become an npm package. I've submitted a PR for the a11y-viewer as CLI tool (#15) and that only makes sense if this project is published to npm. We can keep doing that manually like we do for other projects, but we could also try out Semantic Release. The result should be automatic versioning, changelog updates, GitHub and npm releases as a result of merging PRs which follow the conventional changelog format.

I've seen it as part of the Egghead.io course How to write an open source JavaScript library. That could help us set everything up. Each step in that course could be a separate issue / PR. For this repo I think we are currently at the step "Publishing to npm".

@jpsc has set up most of the tooling around our other open source projects. Maybe he could help out here.

See: https://developer.mozilla.org/en/docs/Web/CSS/cursor

This would allow you to share a link to the a11y-viewer with a site opened inside it.

Example: https://voorhoede.github.io/a11y-viewer/#url=https://www.voorhoede.nl

So update has at the same time iframe source is changed.

Change iframe source to url in hash on viewer load (and hash change?)

In contributing now build, start, watch npm scripts are described. Let's describe all available ones.

Currently the a11y-viewer is only an in-browser tool. We could extend the functionality to also render the result to an image file. This would allow us to serve these images to browsers not supporting SVG filters. And we could extend the CLI tool (#15) to support rendering to a file (a11y-viewer https://example.com --output example.jpg). If we want to make this useful on the CLI the "severity level" and "color blindness type" should also be supported options (related to #18) otherwise we'd just be rendering plain screenshots.

We could use Phantom or maybe Headless Chromium to render the image. And could make adding the filter a second step.

JS will fail in browsers not supporting classList etc.
Only execute script in capable browsers. Give others a fallback.

On smaller screens the viewer tools are hidden in an expandible menu.

The form elements should be full width (max 100%) on those smaller screens.

The scripts for inlining script and css are quite basic. It eats errors for example. Let's implement some erro handling. We have a tooling recipe which is a bit more battle hardened. See https://github.com/voorhoede/front-end-tooling-recipes/blob/master/postcss-process-and-watch/scripts/postcss.js

When you only set the url parameter in the url it breaks. Shall we make all url parameters optional?

Same as #3, but for "severity" and "color blindness type". This would allow us to link to specific variations like "example.com with moderate visual impairment and protanopia". And that's useful for sharing with others (designers, product owners etc).

CSS filters has less support then SVG filters.

http://caniuse.com/#feat=css-filters
vs.
http://caniuse.com/#feat=svg-filters

The a11y-viewer hosted on GitHub Pages has some limitations, including:

• only pages served over HTTPS can be tested as GitHub Pages also runs on HTTPS.
• only pages without the X-Frame-Options: SAMEORIGIN header can be tested as we're using an iframe to load the test page.

HTTPS is not a restriction when the a11y-viewer is served from the localhost. But the iframe issue remains. For this I suggest we add a proxy option. Instead of loading the test page directly in the iframe we proxy it through a local server and use it's address as iframe[src].

If the CLI feature (PR #15) makes it into the product we could do something like this:

a11y-viewer https://google.com --port 1119 --proxy --open

Normally google.com can't be loaded due to the X-Frame-Options: SAMEORIGIN header. If we proxy this locally over http://localhost:77699 ("proxy" in T9), we just use this when opening the viewer in browser. So instead of http://localhost:1119/?url=https://google.com, we'd open http://localhost:1119/?url=http://localhost:77699 or if we want to hide implementation something like http://localhost:1119/?url=https://google.com&proxy=77699. I'd only want to add this for local testing (using the CLI tool) as I don't want to create some generic proxy out in the open which anyone can abuse.

Use node-http-proxy?

Instead of opening on voorhoede.nl, start with an introduction. Include:

• motivation for a11y-viewer
• link to background reading material / info on different types of (color) blindness etc.
• list (lik to) examples of good and bad sites
• explain limitations (HTTPS, iframe allowed)
• link to used resources: SVG filters, Udacity a11y course

Good examples:

• https://www.gov.uk/

to save requests and enhance (perceived) performance.