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

41–50 of 93 posts

Re: Tota11y

#41

Post by locokoko »

JoshTriplett wrote: post #35
locokoko wrote: post #31

Earlier quoted context omitted.

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 :)

Re: Tota11y

#42

Post by Rifu »

pjc50 wrote: post #36
Rifu wrote: post #27

Earlier quoted context omitted.

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).

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...

Re: Tota11y

#43

Post by mkozlows »

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?

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.

Re: Tota11y

#44

Post by simonpantzare »

agentgt wrote: post #18

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).

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).

Re: Tota11y

#45

Post by prezjordan »

agentgt wrote: post #18

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).

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.

Re: Tota11y

#46

Post by prezjordan »

corney91 wrote: post #4

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.

Re: Tota11y

#47

Post by agos »

amyjess wrote: post #40
JoelSutherland wrote: post #34

Earlier quoted context omitted.

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.

Re: Tota11y

#48

Post by prezjordan »

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

Re: Tota11y

#49

Post by paulirish »

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

Re: Tota11y

#50

Post by prezjordan »

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 well.

Post reply on HN