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.
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
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.
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.
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!
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?
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.
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.
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...)
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 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.
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).
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?
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.
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.
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.
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 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.
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.
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.
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.
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.
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?
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.
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).
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:
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."
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.
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.
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
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.
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]
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.
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.
<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.
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