Tota11y | Hacker News Reader

Tota11y

khan.github.io

747 pointschrtze91 comments

Hey HN!

I built this utility with the help of two colleagues[0][1] after working on accessibility at Khan Academy for a few weeks, and seeing first-hand the process of evangelizing accessibility on a dev team. Our automated tests were far from approachable (and became more annoying than helpful), so we built tota11y to make the manual testing experience more interactive and educational (we like teaching things).

I touch on this in our engineering blog [2]

Anyway, super thrilled to see tota11y near the top of HN this morning, and happy to answer any questions you may have.

[0]: https://twitter.com/himichelletodd

[1]: https://twitter.com/rileyjshaw

[2]: http://engineering.khanacademy.org/posts/tota11y.htm

This project arrived at the right time. We're adding accessibility insight & debugging tools like this directly into the Chrome DevTools and the lead developer of the Chrome Accessibility Developer Tools extension is leading the effort. Our mocks actually look quite similar to what you have here and I'll definitely ping you separately to get feedback on what the browser can do to help. Thanks

Hey Paul,

Love the work Alice & co are doing. We're big users of Accessibility Developer Tools (https://github.com/GoogleChrome/accessibility-developer-tool...) at Khan Academy both as part of our automated testing process and now as part of tota11y.

Really excited to see it to make its way into DevTools proper! Been rocking the extension for a few months now.

Nice, what would be cool is to have something like this online (as a service), that could fetch a page and make a report.

The report could then be shared with web designers who use an insufficient contrast ratio between their background and their text for instance, no need to be visually impaired to be bothered by sites who do that kind of stuff, and they are way too many.

Nibbler[0] and pa11y[1] will handle that use-case for you. I've only used either a little. I really like the idea of catering these reports to designers, though!

[0]: http://nibbler.silktide.com/

[1]: http://pa11y.org/

WAVE[1] at WebAIM will do this for you. It was built by a non-profit dedicated to online accessibility. Just type in an address and go. They also have a Chrome plugin [2] that runs the same accessibility checks in your browser and produces a report. I found it very helpful on a recent accessibility project. Nice to see more developers caring about this.

[1] http://wave.webaim.org/

[2] https://chrome.google.com/webstore/detail/wave-evaluation-to...

Great job, love it! It would be really cool if you had a toggle for implementing the suggestions, so you could instantly see if a suggested change looks better.

Thanks :) We've got an issue open for this - https://github.com/Khan/tota11y/issues/21, so hopefully coming soon.

Awesome tool, thank you for making this available to the community! I'm going to take a crack at integrating this into our ember application and (hopefully) cut back on some of the support. Is there any formal ember-cli support in the works?

Nope no formal support. I'm not terribly familiar with ember-cli, but I'd love to hear how we can make it easier to use tota11y with any codebase.

I'll post this here since people interested in accessibility will be reading this thread.

I have terrible vision. One of my pet peeves is when I go to a website on my phone through safari that doesn't allow me to zoom the text. For those occasions, I came across a JavaScript bookmark that I created on my phone that runs to undo whatever is preventing me from zooming in.

I'm not a web developer (I do desktop/server software development), so I have no idea how or why certain pages implement this policy/style. It just seems a little arbitrary to choose a font size for your site and not allow visitors to zoom-in in case they have trouble reading the text.

I agree — disabling zooming is frustrating. Have you tried the "Reader" option in Safari? It works well for a lot of websites.

The reader option is awesome when it exists, but there's currently no way to set a site to always enable it. Safari itself makes the determination on a page by page basis. Or at least that used to be the case.

I believe one of the reasons for preventing zoom-in is because it plays havoc with any element that is "fixed" in your browser (ie pretty much every nav bar/fixed header you'll ever encounter).

Also screws with ad layout and visibility. For sites that are primarily beholden to ad revenue, that can be a dealbreaker.

I just ran into this very problem.

My workaround includes checking the window width with JQuery and changing the fixed status box (originally on the right side of the page) to floating at the top should the width be below a certain margin.

Is this an acceptable solution?

(I am just beginning web dev in lisp)

I think you can get the right result with a media query, assuming those are recomputed on zoom, which they should be.

Thanks, works perfectly. Now I can delete some unnecessary JS :)

That's a reason to set appropriate scale factors, not to prevent zooming entirely.

If zooming is disabled, the browser can respond to clicks without a 300ms delay since it doesn't have to wait for a double-click zoom. It seems like the best solution to this problem would be to make a global toggle in settings.

Alternately, you can just require multitouch zoom and get rid of the antiquated notion that you can double-click to zoom.

Double tap to zoom is a standard gesture for mobile Safari, hardly antiquated.

That's true, but given that pinch to zoom is nearly ubiquitous, and given that the double tap gesture requires a 300ms lag before responding to single taps, the Web would arguably be better without it.

I can confirm that working around this issue is horrible. That dastardly 300ms makes quick operation of a mobile app a complete pain in the arse. Constantly having to wait for iOS to catch up with you. It really makes the experience horrible.

But that's how iOS want it. If they made webapps that performant then they'd have trouble imprisoning everyone in the App Store.

How? It should just zoom the viewport, there's no reason for any of the DOM elements to even be aware that it's happening. Or has this been implemented in a really stupid way?

I'm not too familiar with it myself, but if I had to hazard a guess it's because setting an element to display:fixed breaks it out into its own root stacking context[0], and browser zoom affects every stacking context[1].

Would love to hear from someone who's actually familiar with what's going on though.

[0] http://updates.html5rocks.com/2012/09/Stacking-Changes-Comin...

[1] https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Under...

While we're at it, please also get rid of fixed elements, especially on mobile devices. They obscure parts of the page for limited value, and they often break in horrible ways.

But with more and more mobile web browsers hiding the address bar, how is that person reading over your shoulder going to know what's the name of that awesome site you are viewing?

This is the solution...

Even 'zoom' on fixed elements as dastardly as it looks is easier to read than text that is too small.

The only legitimate reason I know of: if your site is interpreting touch events directly, and you use pinch-to-zoom yourself; for instance, full-page maps. In that case, it's your responsibility to make all your non-zooming elements (such as the fixed UI overlay on the map) appropriately sized for the device.

For what it's worth, using the viewport meta element to disable zoom is a WCAG AA accessibility violation: http://www.w3.org/TR/mobile-accessibility-mapping/#zoom-magn...

That seems to focus on font size adjustments, which would be unaffected by a meta viewport, no?

"Magnify browser's viewport (typically "pinch-zoom")"

That is exactly what is disabled when authors disable zoom via the meta property.

Right, but it's not what the relevant accessibility standard focuses on. It's the difference between zooming the whole page and making just the text bigger (i.e. through a browser's minimum font size setting), and it's only the former that's affected by meta viewport tags, no?

As some who also has terrible vision -- dedicated text sizing is awesome, but being able to just pinch-zoom makes ALL the difference for me. So many aspects of a web page are hard to use other than just text as well. (Those "X" close icons can get pretty damn hard to decipher at times.)

No solution is perfect, but allowing zooming is simple and a huge win for me. (Even if the site still has a sticky header that wont get out of the way...)

This is a little off topic, but if you use Chrome on Android you can disable site's ability to disable zoom.

- Open Chrome (or Chrome Beta) on Android.

- Settings -> Accessibility

- Force enable zoom (check).

Sites may need to be reloaded after applying this setting.

For that matter, you can also set a default text-scaling level as well (mine is at 130%), which I tend to do in addition to force enable zoom. Many sites have fonts that are too small on a phone imho... they really should be at least 12pt for most text assuming that proper scaling meta is set... Too many sites use 9-10pt fonts which are just really hard to read.

I'm far sighted, so my phone is literally the hardest thing for me to use much of the time. One of the worst offenders was the Facebook app, which didn't seem to even follow Android's setting for using larger fonts. I've since stopped using the FB app (way too much battery usage), and just use the mobile site, which isn't much better in terms of usability.

This is really great. Just two suggestions.

While minimised, the tab could display a score like A+ - this could incentivise websites to permanently present it on their pages as a badge of pride (while ensuring visibility to any changes that degrade the score).

Secondly, if you link to the project within the maximised tab, you'll likely see greater adoption.

But why would you place this tab on a live site? It's a great tool for developers, but there's no need to place this in production imo.

Yeah spot on. Accessibility is not something you show an award for. It's expected it will work on its own.

It wouldn't be an award, it would be a grade. Compliance and accessibility notices on websites have been used extensively over the years.

But what would be the incentive for other site owners to use it then? It seems like in this scenario, the only time anyone would want to use the tool on their live site would be when they are sure they are getting an A+, any other sites that don't care about that score just wouldn't add the tool and any changes that might lower that score would presumably being taken care of before rolling out to production.

It seems like it would just turn into unnecessary bragging for the site owner. I wonder if the scoring would still be useful for development though, or if they would just try to fix as many problems as possible anyway.

It looks very similar to this tool: https://squizlabs.github.io/HTML_CodeSniffer/

Very handy having things like these as bookmarks.

That's a huge compliment, thank you!

HTML_CodeSniffer is significantly more comprehensive than tota11y, so I encourage everyone reading this to also check out corney91's link.

tota11y takes more of a visualization approach, because in our experience being greeted with several dozen errors which we've never seen before didn't motivate us to keep the site accessible. My aim was to make the experience more interactive while explaining errors (and fixes!) as best I can.

We're still figuring out where tota11y fits in this great big world of a11y testing, but so far folks have responded well to this approach.

Here is a WordPress Plugin for it: https://github.com/omarabid/wp-tota11y

The script will be loaded only if an admin user is logged. So you can rest assured this will not annoy your users.

Maybe I'm in minority, but I'd have preferred a userscript/extension alternative for those who don't use a bookmarks bar.

edit: Never mind, made a quick one for myself seeing that's MIT licensed https://gist.github.com/liviu-/62e8ce91b8723ef1a10a

Definitely not in the minority. Bookmarklet was a little easier to get out the door, and I haven't found a great way to maintain extensions for several browsers. Will definitely up its priority.

Userscript is an awesome idea, thanks for taking the time to build this out. Is this something that will work in all browsers? What's the installation process like? Perhaps we can build one of those into the project page as well.

Although userscripts themselves are cross-browser compatible, I don't know of any browser that offers native support for them. However, there are extensions that manages them (Greasemonkey for Firefox, Tampermonkey for Chrome, etc.) Once the user has a userscript manager installed, the installation process is a matter of a one click job.

Interesting, thanks for the explanation.

Perhaps we can detect if a popular userscript manager is installed and provide a one-click link that way. Not sure if this is possible though.

Chrome/ium apparently has had built-in support for a while:

https://www.chromium.org/developers/design-documents/user-sc...

This is fantastic, I love how it's a bookmarklet, which means I don't have to mess around with bower to make my sites accessible. Great job!

I am surprised the tool doesn't do any color blind checking (ie putting red and green next to each other is generally not a good idea).

I wonder how hard it would be to cover all types of color blindness - red and green is only one possible issue with deuteranopia - there are other potential color combinations within that, and two other types of color blindness as well.

Hmm you could integrate some information about the prevalence of different types of color blindness.

"This color combination causes mild problems for 15% of people and severe problems for 5%. Consider X and Y to reduce impact to 3%"

Does the contrast checking catch that?

The problem is that you'd need to run the contrast test after applying the transform for various types of color blindness because they're fairly different and some seemingly high-contrast color combinations end up fairly similar:

http://www.color-blindness.com/2008/10/02/color-blindness-si...

If you want to test this on your own, http://colororacle.org/ acts as a screen overlay so you can load any sort of application, web page, etc. and hit a hot-key to see what it looks like with each of the different types of color blindness.

WCAG contrast calculations are designed to account for this: "Color deficiencies can affect luminance contrast somewhat. Therefore, in the recommendation, the contrast is calculated in such a way that color is not a key factor so that people who have a color vision deficit will also have adequate contrast between the text and the background."

http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contr...

So if you pass WCAG color contrast checks, you'll be accessible to users with color deficiency as well as low vision.

Good point – unfortunately, it doesn't look like htat's what the plugin here does:

https://github.com/Khan/tota11y/blob/952427485a49bde0f498e9d...

https://github.com/GoogleChrome/accessibility-developer-tool...

Definitely a good feature request

Out of curiosity, are there reasons why this shouldn't be solved at the browser or even OS level? The only reason I can think of is that solutions at the app level makes it possible for people to refer to a blue line, red bar, and whatnot and it means the same for everybody. But if we need many color profiles anyway because there are many kinds of color blindness, perhaps we should just make the labels pop out or have fewer series per graph (so that we can just refer to these graphs instead of individual series in them).

Creator here!

I've heard of some ways to visualize this with SVG filters - so this will be coming soon.

Still thinking of creative ways to find and label the errors, rather than just showing the user how the page will look under a certain type of color-blindess.

Can I ask you something...

So it is complaining that we have a link (A tag) with an image within it. The image has an alt tag. But the addon is claiming the A tag is "empty" and that I should add "screen reader text."

Some googling around suggests that adding "screen reader text" is unreliable since many unrendered texts aren't rendered by screen readers either, and on top of that it can cause element positioning issues.

So why is the alt text unacceptable "text" for within an A tag for when the image isn't rendered? Isn't that the entire point of the alt tag, to provide text for a non-rendered image?

You are absolutely correct in assuming that having alt-text on the image inside the link is accessible.

This is a known bug (https://github.com/Khan/tota11y/issues/1) that comes from upstream (https://github.com/GoogleChrome/accessibility-developer-tool...) and will hopefully be fixed soon.

As for your notes on screen-reader text: you can "hide" it by not actually hiding it, but placing it off the side of the page. This will be picked up by screen-readers and will not cause any positioning issues.

We use the following snippet all over Khan Academy. Bootstrap 3 uses it as well.

    .sr-only {
        border: 0;
        clip: rect(0,0,0,0);
        height: 1px;
        margin: -1px;
        overflow: hidden;
        padding: 0;
        position: absolute;
        width: 1px;
    }

So I'd like to assure you that your image link is good to go (assuming the alt-text is good!). Sorry for the troubles.

Thanks for the reply. I'll add that to our CSS in case we need it elsewhere and ignore the warning about an empty A tag for now.

aria-label is well-supported enough that it's probably better to use that, rather than offscreen text, for most purposes.

The programmer in me loves how accessibility auditing enforces best-practices around semantic HTML, and my business-side loves making it cheaper to reach a wider audience.

Great project!

Oh, I've been looking for something like this. It's definitely going to help me with accessibility.

Really glad to hear that :) Let me know how the experience goes for you!

I remember seeing a chrome extension a while ago that I hoped would be like this, but instead was a plaintext list of guidines and reminders that didn't react to your site at all.

I'm confused about how this is MIT yet to contribute I have to sign a Khan Academy CLA? That doesn't seem ... MIT-y

Is there a plan to able to run this in a CI environment?

If you want a11y testing for a CI environment, take a look at aXe, which is designed specifically for that purpose: https://github.com/dequelabs/axe-core

Awesome, thanks!

To echo mkozlows, definitely check out axe-core. They recently open-sourced the tool and it's chock full of great a11y testing.

At Khan Academy we use Chrome's Accessibility Developer Tools (https://github.com/GoogleChrome/accessibility-developer-tool...) as part of our testing infrastructure. A few of us also have the browser extension to do some manual testing, which is what tota11y is for.

tota11y uses Accessibility Developer Tools internally.

This was on hn 17 and 21 days ago. https://news.ycombinator.com/item?id=9710958 It's nice, I was able to see, via the bookmarklet that my <a> colors are unclear.

Having an <h4> tag below an <h2> tag is an accessibility concern? What does incrementally decreasing in heading size have to do with accessibility?

Couldn't even be bothered to read the explanation, could you?

> "[...] In order to maintain a consistent outline of the page for assistive technologies..."

I read that. I still don't understand how an h4 directly under an h2 impairs accessibility.

1.2

1.2.1

1.3

1.3.1.1

Perhaps screen readers can be set to read out the major headings to help people figure out what part of the document they want to read. This would have a level of detail or verbosity control.

First you read h1, find the right header. Then h2 with 2 levels of detail, which hits h2 and h3. You miss the sub-section you wanted because it was marked h4 instead of h3.

It's a broken tree structure... that'll cause problems any time somebody wants to do a logical traversal.

Yes. Screen readers load the page contents into a buffer and allow users to scan headings, links, etc. having a broken outline structure is potentially confusing [1]. This is also why descriptive linked text is important (ie: no "click here") [2]

[1]: http://www.w3.org/TR/WCAG20-TECHS/H42.html [2]: http://www.w3.org/TR/WCAG20-TECHS/H30.html

Screen readers do indeed have a feature that allows the users to browse just the headings.

As others have mentioned, it's likely flagged as an accessibility issue since having an h4 follow an h2 indicates a broken document structure.

It's also probably included in the tool because things like that usually (though not always) mean that the developer is just using the h4 tag based on how it looks as opposed to actual semantic meaning, and the tool is designed to get you to put more thought into what you're actually building.

Remember the size is a consequence but it means it's a header of a subsection of an h3 which is then a header of a subsection of an h2. It could throw off the emphasis used in some screen readers or screw with a reading layout.

It's honestly probably not a big deal but it is an improper use of syntax and could mess with accessibility software in undesirable ways.

It's a big deal if you care about the semantic structure of a document.

Well true I just meant in a functioning and even accessibility context; it'll probably still work well enough.

As a side note I know almost no one that cares about the semantic structure of an HTML document. It makes me sad. I miss XHTML's rigid structure.

<h4> under an <h2> has nothing to do with accessibility. Its just some people think it makes sense to have smaller headings after bigger ones and not the way around. I for one think that it sometimes is important to use an h2 after an h4. This has nothing to do with semantics btw.

Please try and avoid using heading tags for size alone :) If it's for design purposes, just resize some <span>'s, and let headings (even ones hidden off the side of the screen) define the structure of the document (as we explain in the error description).

The reason for this is because many screen-readers have keyboard shortcuts to jump from heading to heading. Many users will map out the page with this key-binding. Keeping the headings in a good order is very important.

Da basics.... You know, separate content from presentation. Content being the HTML page, and presentation being the styling. Semantically right HTML should be the primary goal when writing HTML. You can than style it 40 different ways using CSS.

Screen readers provide information about headers on a page, and users use that to navigate to the relevant portion of a page. When headers are in sensible hierarchical order, this is easier to do.

That said, while it's a best practice to keep headings in a sensible order, skipping heading levels is not a WCAG AA violation.

dat is awesome!

Many thanks for MIT license, would just ignore this if it had anything with GPL in name.

dat is awes0m3

Reply on news.ycombinator.com