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

31–40 of 93 posts

Re: Tota11y

#31

Post by locokoko »

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

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)

Re: Tota11y

#32

Post by JoshTriplett »

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

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

Re: Tota11y

#33

Post by JoshTriplett »

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…

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.

Re: Tota11y

#34

Post by JoelSutherland »

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

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.

Re: Tota11y

#35

Post by JoshTriplett »

locokoko wrote: post #31
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).

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.

Re: Tota11y

#36

Post by pjc50 »

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

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?

Re: Tota11y

#37

Post by mkozlows »

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…

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

Re: Tota11y

#38

Post by steveax »

edraferi wrote: post #24
ohitsdom wrote: post #12

Earlier quoted context omitted.

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

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…

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

Re: Tota11y

#39

Post by mkozlows »

acdha wrote: post #29
edraferi wrote: post #22

Earlier quoted context omitted.

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…

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.

Re: Tota11y

#40

Post by amyjess »

JoelSutherland wrote: post #34
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).

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.
Post reply on HN