Is it still necessary to use em's and avoid javascript for Accessibility?

[matthijsA]

Still not convinced. Sure, zooming works in many cases. But that's separate from the font size setting. People can still zoom in on individual sites if they want. But for someone with an increased base font setting, setting the base font size in IE in px disrespects that setting. And I still fail to see the big advantage of px, besides making it a bit easier for the developer or giving the website owner the peace of mind that there's not a group of people increasing the font size on their website and by that disrupting the intended design.

Look, the main reason developers hate/have hated using ems/% everywhere is because of the cascading effects of those relative font sizes (rem can be a solution for that by the way). In complicated websites it's much easier to just use px everywhere and you're sure the browser shows exactly what the designer delivered in his/her psd comp. But if you've already done all the calculations of the relative sizing within the stylesheet and only have body font-size to set, why set it in, for example, 16px instead of 1em? I fail to see it.

Not sure how we can make some progress in this discussion.

[itmitică]

I don't use px because it's easier for me that way. I'm perfectly capable of using em alone. I'm using it, just not for baseline. Doing that, it doesn't make em less useful. In fact, em is intended for that: to represent an assigned value in an easier way to deal with inside the developer's stylesheet: calculations, proportionality. It's job is not to "respect user wishes". That's bubkis.

Also, em is not intended for naive calculations like 0.6235221525636. This one negates the whole point of using em, if you want such an example.

If you fail to see the advantages of px, you probably didn't come across the right project where it comes handy.

I, on the other hand, see more than one advantage for using em (or maybe different advantages), and I also see the pitfalls it has. For me and my work and my technique.

My whole point, em or px, that's a choice and it should remain a choice. You're asking to remove that choice. That's a bad thing. Good developers can handle both. They can fix issues for both. They can exploit both in a safe way. The misunderstandings appears when someone embraces em for the wrong reasons: to get away with accessibility.

[deathshadow60]

It improved your loading time as well:

Shouldn't have -- there were zero changes to the desktop layout and the mobile is loaded over desktop, so it should be the same as ever.

It seems that the issue it had with the boxSir.css is now gone. Probably because of the meta viewport you added, it's processing that faster?

Yeah, Safari under iOS wants to automatically resize EVERYTHING... I've added another property now -- This went into my 'reset':

-webkit-text-size-adjust:none;

Which made a noticeable boost and FINALLY has it displaying how I want it to display... Because IMHO even for handheld that text was too big. (me complaining about text too big?)... also had a friend comment on the excessively large content text and how it was shrinking the 'sidebar' text.

edit: It still has that noticeable lag when scrolling on the tablet. On Firefox Mobile, Dolphin, Android Browser. Your elastic layout is too demanding, perhaps.

the elastic layout really isn't the problem. It's the CSS3. All those nice fancy box-shadows, text-shadows and other effects really suck down the CPU, and handhelds just don't have that much CPU. For all the bragging about how ARM is faster per clock than x86, I've not seen that be factual since Intel gave us the original Core 1. (though everything they say about power to processing remains true).

... and for all Apple's bragging about their unique A4 processor, it's still just a licensed crappy little ARM Cortex A8 with a PowerVR 535 video chipset; about equal to a ATI Rage FX circa 1998.

I'm debating if I should axe the CSS3 for mobile or not... As it is I might drop all the -moz prefixes given what absolute rubbish CSS3 is under FF.

[itmitică]

Shouldn't have -- there were zero changes to the desktop layout and the mobile is loaded over desktop, so it should be the same as ever.

Yet it did.

This went into my 'reset':

-webkit-text-size-adjust:none;

I use normalize.css: http://necolas.github.com/normalize.css/.

You should take a look at it, as it has this one in it:

/* =============================================================================
Base
========================================================================== */

/*
* 1. Corrects text resizing oddly in IE6/7 when body font-size is set using em units
* http://clagnut.com/blog/348/#c790
* 2. Prevents iOS text size adjust after orientation change, without disabling user zoom
* www.456bereastreet.com/archive/201012/controlling_text_size_in_safari_for_ios_without_disabling_user_zoom/
*/

html {
    font-size: 100%; /* 1 */
    -webkit-text-size-adjust: 100%; /* 2 */
    -ms-text-size-adjust: 100%; /* 2 */
}

[deathshadow60]

If you fail to see the advantages of px, you probably didn't come across the right project where it comes handy.

Actually, there are places I will use PX -- usually when there's a image interaction or I'm forced into a column that would break with the auto-resize; but as a rule I avoid those situations for anything past the main menu on a page. My h1 under the logo/title image for example is most always PX...

It's just when it comes to the CONTENT, what people actually visit the page for, that I take issue with it. There are people who advocate "NEVER USE PX" -- I'm not in that crowd... You're right, it's a choice.

Just, don't choose it on content paragraphs -- the parts people actually came to the site FOR. Likewise for relevant headings as they too are content. Really if in your content area you've added something that can't handle the automatic resize EM provides, then you need to rethink your presentation. I see that a lot on pages, elements that IMHO just arent' viable for web deployment in the first place.

Stupid massive banner areas with maybe four to five words in them top the list, followed by fixed height backgrounds with multiple lines of content text in them. You choose to do those, you choose to alienate some users.

Like with yours -- that would annoy me no end on mobile because your first two scrolls don't even have anything meaningful on them -- it looks broken and/or empty. I'd consider using those media queries to remove that entire banner area where you have the h1 text and language toggle, and shrink those down so people can actually get to the content of the page. Likewise I'd be dropping a LOT of the excess padding so as to get more to the user.

While on mine... I'm noticing a major mobile issue; really bad "wall of text". I may have put too much on one page.

[deathshadow60]

I use normalize.css:

You should take a look at it

I have, fat bloated rubbish I'd not even put on a site in the first place, that sets a bunch of values that provide absolutely nothing I'm not already doing myself with different values... 10k, and even 3k with comments and whitespace stripped is massively bloated nonsense that just makes MORE work, not less. It takes everything that's wrong with Meyers idiotically bloated "reset reloaded", and doubles it! That's not a 'reset', that's not a 'normalize', it's a FRAMEWORK... and CSS frameworks are universally rubbish.

Admittedly, MOST of it is support for html 5 asshattery which as of right now I have no future plans to even CONSIDER deploying.

[itmitică]

Like with yours -- that would annoy me no end on mobile because your first two scrolls don't even have anything meaningful on them -- it looks broken and/or empty. I'd consider using those media queries to remove that entire banner area where you have the h1 text and language toggle, and shrink those down so people can actually get to the content of the page. Likewise I'd be dropping a LOT of the excess padding so as to get more to the user.

Right now I'm working on a new system for back-end, but I'll get back to it and I'll definitely reconsider. Thanks.

[itmitică]

I have [...] it's a FRAMEWORK...

Well, you could at least look at the issues it tackles and take only what's good for you from it, you don't have to use it as is. It has a different view: 100% instead of none for -webkit-text-size-adjust. They probably did some tests (it's also based on reports). More heads are better than just one.

[deathshadow60]

It has a different view: 100% instead of none for -webkit-text-size-adjust.

My understanding of it is that :none disables the auto-resize engine completely, while leaving it at 100% keeps the multiply in there... dunno if that's factual or not though.

... and I did glean one useful bit from normalize -- I've not seen auto-resize with a IE prefix before. Must be for 9 on mobile or something. Funny since they're skipping right over IE 7 and 8 for mobile... Though reading through it's ignored if the viewport meta is present... if I pull the viewport meta, I have to test for device-width in addition to width since iOS lies about width.

[itmitică]

My understanding of it is that :none disables the auto-resize engine completely, while leaving it at 100% keeps the multiply in there... dunno if that's factual or not though.

If you read the comments, it says why:

* 2. Prevents iOS text size adjust after orientation change, without disabling user zoom
* http://www.456bereastreet.com/archiv...ing_user_zoom/

-webkit-text-size-adjust: 100%; /* 2 */

I've tested it on your site and it's true: I can't "pinch" it anymore with your "none".

[deathshadow60]

I've tested it on your site and it's true: I can't "pinch" it anymore with your "none".

Actually, I believe that's the values in the viewport meta -- I'm going to have to play with that. Downloading the now 7 fracking gigabyte latest xCode, which is supposed to have an accurate iPhone 4 emulator in it -- then I can play with things like that a bit more.

Though I'm unsure how one tests pinching for zoom with a mouse :/

[itmitică]

You're right, it's the viewport meta.

Well, I use this viewport meta:

<meta content='width=device-width, initial-scale=1.0' name='viewport' />

and together with the CSS in normalize

html { font-size: 100%; -webkit-text-size-adjust: 100%; -ms-text-size-adjust: 100%; }

it leads to the behavior you'd want?

I don't know if/how pinching works with the mouse either... xCode docs.

[itmitică]

One thing I noticed just now, Firefox Mobile also uses viewport meta, or impedes on it, at least.
I had a glitch in my meta for the /en/ and I just now found it (a "=>" instead of "=")
That lead to a difference in render I didn't know where to look for until now.

The funny thing is that iOS's Safari and the others I tested could actually get past that and render consistently.
Granted, Firefox Mobile is still beta.

[matthijsA]

I don't use px because it's easier for me that way. I'm perfectly capable of using em alone. I'm using it, just not for baseline. Doing that, it doesn't make em less useful. In fact, em is intended for that: to represent an assigned value in an easier way to deal with inside the developer's stylesheet: calculations, proportionality. It's job is not to "respect user wishes". That's bubkis.

Also, em is not intended for naive calculations like 0.6235221525636. This one negates the whole point of using em, if you want such an example.

If you fail to see the advantages of px, you probably didn't come across the right project where it comes handy.

I, on the other hand, see more than one advantage for using em (or maybe different advantages), and I also see the pitfalls it has. For me and my work and my technique.

My whole point, em or px, that's a choice and it should remain a choice. You're asking to remove that choice. That's a bad thing. Good developers can handle both. They can fix issues for both. They can exploit both in a safe way. The misunderstandings appears when someone embraces em for the wrong reasons: to get away with accessibility.

itmitică, please stop putting words in my mouth, stop setting up stawman arguments.
"You're asking to remove that choice". I never said this. To the contrary, I have pointed out multiple times that there are always pros and cons for each thing in each situation, and therefore developers have to make informed decisions in each situation.

"The misunderstandings appears when someone embraces em for the wrong reasons: to get away with accessibility". Who said this? Certainly not me. On many occasions I pointed out that this em/px issue we are talking about is just one of many issues to deal with when building a website.

Look, I have been using px for body font size on many websites as well. For the same reason you do: easier. In the early days, when IE5 and 6 were still widely used, I would use em/% for accessibility reasons. Then, when IE7 and 8 came I switched to using px, because these browsers could zoom. I thought, like many did, that's it wasn't an accessibility problem for IE users anymore. But then after reading a bit more, giving it some more thought and realizing that even recent versions of IE still don't resize text set in px and don't respect any changed default font setting, I have switched back to using a base em/% size on body again.

And, just testing this morning, I realized that even browsers like Firefox, Chrome and Safari don't respect the users' setting when using px. Try it yourself: set the font size to 40px or something in the settings of Firefox, Chrome or Safari. Open a test page with body font size set to 16px. You get to see 16px text. Even though in the preferences of the browser you had set it to 40px/very large (depending on the browser this is different). Set the test page body font size to 1em and reload. Nice, 40px text size.

You could of course say that this is the intended behavior from CSS' perspective. When I set something to 50px, it should be 50px. However, when I think about text content on the websites I build, I want that text to be as accessible as possible.

So the problem with px is even worse then I thought. There are now two issues to think about when using px:

1) IE users not being able to resize the font size, even on a site by site basis. Only zoom in recent IE versions

2) Not respecting users' setting of a different font size, in both IE and other browsers like Firefox, Safari, Chrome

[itmitică]

And, just testing this morning, I realized that even browsers like Firefox, Chrome and Safari don't respect the users' setting when using px. Try it yourself: set the font size to 40px or something in the settings of Firefox, Chrome or Safari. Open a test page with body font size set to 16px. You get to see 16px text. Even though in the preferences of the browser you had set it to 40px/very large (depending on the browser this is different). Set the test page body font size to 1em and reload. Nice, 40px text size.

If just this morning you realized that, I'm firmly stating again that you don't posses yet the technical knowledge required for this discussion. Reading the above makes me think that you've been blindly using em as a particular solution, to get away with accessibility, without really knowing the purpose or the meaning, both solution's and em's. I apologize if it offends you, but that's my conclusion.

As a side note, you should remember I told you how the Dolphin browser knows how to handle and override developer's settings, px or not, in favor of the user's: Tiny, Small, Normal, Large, Huge. If it's good or bad, that's also a decision vendors make. Microsoft decided to honor developer's settings above user's. It gave the user the zoom options, a solution that works no matter. An equal solution, that is, that is no less or no more useful or problematic.

It's my opinion that any technical fact or solution I may throw at you, it'll just go over your head at this time. In the light of that, this is the single most revealing thing I have left to tell you: it's about browsers respecting developer's settings too and it's developer's duty to assume that. From now on, the only thing that either makes or brakes accessibility is the developer it self. I'm just fine with you thinking I'm breaking it.

But, I don't use px because it's easy, I assume using px because I can manage to deal with the possible issues appearing. Are you perfectly sure you can say the same about your em choice and its possible issues? That's all I'm asking.

Your choices are yours, I can handle mine. Period.

[itmitică]

Is it still necessary to use em's and avoid javascript for Accessibility?

I'm going to try and lay down my final thoughts.

In an ideal world, all websites would have an Accessibility entry in their menus:

Accessibility
  o Normal
  o Accessible
  o Accessible+

In an increasingly ideal world, this entry would be found in browser's menus.

Browsers would have advance algorithms in place. They would analyze dpi, browser window size, resolution, developer settings, user settings and put them all together and give a true accessible experience, including screen reading.

Developers would do their part. They would help browsers with smart fluid, elastic or whatever designs, using microformats or role attributes to add data to be used for accessibility.

Users will only have to know how to click or tap on the desired option: Normal, Accessible, Accessible+.


Going back to the real world, the question remains: Is it still necessary to use em's and avoid javascript for Accessibility?

That's a naive question, for me.

Using em will not grant accessibility. Javascript will not break accessibility. Only developers will make that happen. Developers may break accessibility put in place by users or browsers. Users and browsers alike also may break the developer's granted accessibility. And more combinations.


Simply put, using em may help some developers, to give them a start. It doesn't mean it's done.
And Javascript can actually help accessibility. It can programmatically substitute the missing simple three options in browsers: Normal, Accessible, Accessible+.


Right now, the developer can use whatever it may wish: em, px, Javascript.
It just has to be able to:
- provide a elastic, fluid or whatever combination for a good design.
- pay attention to all that's needed when putting things together: HTML, CSS, Javascript, with all media queries and such.
- do extensive testing; that's where to truth lies.

[matthijsA]

I will make a formal complaint about you continuing to attack me personally. "you not possessing the technical knowledge required", "blindly using em", and many remarks like that are playing it on the man, wrong and not adding anything of value to the discussion. I ignored them so far, but you keep making them.

I am bringing forward actual technical arguments about the subject. Explaining how and in which situations what happens when a website is coded with em and/or px as base font size. Facts. You are allowed to give your insights the same way. What happens in which situation, in which browser, etc. If I make a mistake ("browser X does A in situation X"), it is very much appreciated if anyone would point out the mistake ("sorry, but browser X does B in situation X"). But so far, the only thing you do is attack me personally or attack me on points I never made.

[Stomme poes]

Hmmm... not at all consistent with the emulator that come's with Apple's xCode... which is officially the test;

Emulators are never to be trusted as the real thing. I don't care if Steve Jobs comes from the grave and promises on everyone else's grave that this is the official test. It's an emulator.

Don't set scales in that meta tag!! leave it be. Arg
change this

<meta
  name="viewport"
  content="width=device-width, minimum-scale=1.0, maximum-scale=1.0"
/>

to this

<meta name="viewport" content="width=device-width, initial-scale=1.0">

set the scale to 1, but for the luv of teh gods let people change that.

[deathshadow60]

set the scale to 1, but for the luv of teh gods let people change that.

I tried that, looks fine in portrait, in landscape it insists on showing the portrait version blown up instead of switching to the 480 layout...

Mein gott they took something simple (media queries) and made it a disaster.

[ralph.m]

Though I'm unsure how one tests pinching for zoom with a mouse :/

Hold the Option key as you drag.

[RyanKing1809]

I tried that, looks fine in portrait, in landscape it insists on showing the portrait version blown up instead of switching to the 480 layout...

Mein gott they took something simple (media queries) and made it a disaster.

The iphone 4 is 960x640px Would this be the issue?

[Stomme poes]

in landscape it insists on showing the portrait version blown up instead of switching to the 480 layout...

is landscape 480px wide?

When my site re-do is done I'm hoping to get some testing on it done on a friend's iThing, but I've been able to test on husband's Android Something and it switches nicely. However I deliberately forced iThings to "mobile" stylesheet by starting the first media query at 482px. You need landscape to see whatever's higher than "mobile" on iThings. This, because I won't write for iThings.

I have a general mouse-turd-and-below basic CSS, then something hitting wide PDA's/tablets/small desktops, then a larger-than-800-friendly setting. IE just gets a conglomerate of these unless I want responsiveness for like a Windows Phone or something. Three style sets is really pushing it for me. I've seen sites with 6 different stylesheets and I'm wondering why the f????...

[itmitică]

I tried that, looks fine in portrait, in landscape it insists on showing the portrait version blown up instead of switching to the 480 layout...

Mein gott they took something simple (media queries) and made it a disaster.

It's a bug.
Following the link in normalize.css I suggested

* 2. Prevents iOS text size adjust after orientation change, without disabling user zoom
* http://www.456bereastreet.com/archiv...ing_user_zoom/

-webkit-text-size-adjust: 100%; /* 2 */

you'll find that it states this:

[...] changing orientation from portrait to landscape scales the page up. This seems like a bug and has been reported to Apple – see a bug report and test case for the scaling bug: http://filamentgroup.com/examples/iosScaleBug/

It also says this:

[...]this is not a perfect world, unfortunately. As I have already mentioned, Safari still auto-zooms when you change the orientation to landscape. However when you pinch the page to zoom out, the text scales down and snaps to the same size as in portrait orientation. Adding maximum-scale=1 to the viewport meta element removes the need for this, with the – in my opinion – showstopping drawback of completely disabling user scaling. Please don’t do that.

What Mallory says.


If pinching it down is not on your linking (I am liking it, like I'm liking the zoom option the user has on desktop ), then you're left with a Javascript solution. I don't remember where I've seen one, I know it exists, but since I didn't believe it is necessary I didn't bookmark it.


I've set my self the lowest target width to be 480px as well, the lowest resolution acceptable for me being 320x480, where the user only needs to switch to landscape.

I'm using these two together, as I've said

I use this viewport meta:

<meta content='width=device-width, initial-scale=1.0' name='viewport' />

and together with the CSS in normalize

html { font-size: 100%; -webkit-text-size-adjust: 100%; -ms-text-size-adjust: 100%; }

as the article recommends also, but you can take a look at http://stuffandnonsense.co.uk/projects/320andup/ too. I believe this is where I saw the Javascript fix for that?

[itmitică]

Yes, I did some digging and it's in the Mobile ★ Boilerplate they're using: http://html5boilerplate.com/mobile.

Reading the docs for Mobile ★ Boilerplate, in the wiki page, https://github.com/h5bp/mobile-boilerplate/wiki, under the JavaScript Helper entry, there's the MBP.scaleFix solution, and the thread explaining it: http://www.blog.highub.com/mobile-2/...ort-scale-bug/, dated almost exactly a year ago.

Interesting to note about Mobile ★ Boilerplate, the

v3.0 Changelog:

index.html

Removed initial-scale=1.0 from meta

I didn't really bought the MBP.scaleFix solution, it has too much going on for it to work, and the near future seem to make it prone to break, but it's work of fellow developers that cared enough to share it with all of us. I can respect and admire that.

Off Topic:


Yeah, it's an HTML5 boilerplate, and some may hold that against it, but the research alone in it has great merits. This is about more heads being better than just one, flexibility, being receptive and open to new things, and the power these concepts have in the real and practical world. It saves time, it gives you a higher starting ground.

Like I said, you can learn from a rock. Unless you're the rock it self.

[deathshadow60]

Off Topic:

Hold the Option key as you drag.

.. and I do that with an IBM model M keyboard how exactly? :P