Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tota11y

khan.github.io

Post reply on HN
Print view View original

51–60 of 93 posts

Re: Tota11y

#51

Post by prezjordan »

paulirish wrote: post #49
prezjordan wrote: post #48

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 to…

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.

Re: Tota11y

#52

Post by prezjordan »

Joe8Bit wrote: post #7

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

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.

Re: Tota11y

#53

Post by aikah »

prezjordan wrote: post #48

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 to…

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.

Re: Tota11y

#54

Post by prezjordan »

sparaker wrote: post #14
ohitsdom wrote: post #8

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

under an 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 '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.

Re: Tota11y

#55

Post by prezjordan »

aikah wrote: post #53
prezjordan wrote: post #48

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 to…

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/

Re: Tota11y

#56

Post by liviu- »

prezjordan wrote: post #50
liviu- wrote: post #6

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 w…

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.

Re: Tota11y

#58

Post by jakobegger »

Rifu wrote: post #27
metaobject wrote: post #21

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 so…

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.

Re: Tota11y

#59

Post by acdha »

mkozlows wrote: post #39
acdha wrote: post #29

Earlier quoted context omitted.

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…

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 p…

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

Re: Tota11y

#60

Post by Someone1234 »

metaobject wrote: post #21

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 so…

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.

Post reply on HN