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

[RyanKing1809]

Ever since I've started posting here I've had @deathshadow60 on my back about accessibility - which is a good thing as I would of never considered it otherwise. And as a result I've been trying to avoid javascript as much as possible and have been using em heights.

But I've been doing some reading:
http://davidbcalhoun.com/2010/does-i...rather-than-px
http://stackoverflow.com/questions/5...-accessibility
http://www.brucelawson.co.uk/2011/ja...screenreaders/

These articles state that all modern browsers can zoom correctly with pixel-sized fonts and only 1.6% of those using screen readers have js disabled.

Do you agree with these articles, in that I can go around setting fixed-pixel fonts and using javascript without worrying about it affecting accessibility? Are these accessibility concerns over a decade old?

[Jeff Mott]

Yes, you can use pixels. Avoiding px was only ever a concession for IE6. IE7 and newer can do full page scaling.

And yes, you can use JavaScript. HOWEVER, you still need to think about accessibility. There are actually several potential issues you'll need to be aware of, so here are a couple links that may help.

http://webaim.org/techniques/javascript/#accessibility
http://www.yuiblog.com/blog/2010/08/16/video-lembree/

[xhtmlcoder]

The px unit is still dependant on a reference 96dpi and thus em is more suited for fonts.

I surf without JS, so don't always rely upon statistics or focus on AT only - many users with disabilities like myself that may have problems surfing don't use AT.

Even if it were 1% (non JS) the small percentages of big numbers are also big numbers. Again, it doesn't question selective blocking of script(s) either. So keep in mind 'progressive enhancement'.

[Mat30]

...I would never [have] considered it otherwise.

I am glad that you admit that and particularly glad that you are now considering it, but this is what causes me to despair about this profession on an almost daily basis. How on earth can any developer not consider accessibility? That is as silly as not considering the possibility of fitting a roof when building a house. I also get quite peeved by talk of percentages: as if a small percentage of mankind does not matter for some unjustifiable reason. The web needs to work to an acceptable level for damn-near everyone: as many people as possible. Developers need to realise that it does not always require additional work, but does require a practical change in how they work and think. If I encounter a website that does not present as much of its content as possible in HTML and instead sticks it all behind some JS rubbish, that is the developer's fault for not doing things right, yet they would give you the impression that it would be my fault for using a browser that does not support JS. And yes, it is not just about JS being disabled.

Anyway, I feel better now that I got that off my chest.

[Stevie D]

Ever since I've started posting here I've had deathshadow60 on my back about accessibility - which is a good thing as I would of never considered it otherwise. And as a result I've been trying to avoid javascript as much as possible and have been using em heights.

But I've been doing some reading:
http://davidbcalhoun.com/2010/does-i...rather-than-px
http://stackoverflow.com/questions/5...-accessibility
http://www.brucelawson.co.uk/2011/ja...screenreaders/

These articles state that all modern browsers can zoom correctly with pixel-sized fonts and only 1.6% of those using screen readers have js disabled.

Do you agree with these articles, in that I can go around setting fixed-pixel fonts and using javascript without worrying about it affecting accessibility? Are these accessibility concerns over a decade old?

I would still avoid using px to specify font size, for two reasons. First, it lulls you into a false sense of security that you think you are specifying an exact size that every browser will faithfully replicate, and that just isn't the case – you still need to be aware of the need for you design to flex and bend. It's purely psychological, but if you're using ems then you are more likely to be in the right mindset.

But secondly, and more importantly, there are still accessibility/user-friendliness issues around setting the font size in pixels. Yes, IE7+ allows users to zoom in, but it also gives them the option to change the text size without zooming, and it still won't change the size of text that is given in pixels in this context. By the same token, some people have the default font size on their browser set to a larger size so that all websites will appear at that larger size so that they can read them – if your size gives the text size in pixels then this will override their settings so they will have to zoom (which often doesn't give a perfect result) – sure, they can solve the problem, but there shouldn't have been a problem there for them to solve. They had their computer set up right for them, and some web designer's arrogance has undone their efforts.

In terms of scripting, you absolutely need to avoid reliance on Javascript for essential navigation and functionality, unless your site includes features that are not feasible to achieve without JS. Accessibility isn't just about screen readers, it's about ensuring that anyone, in whatever context or situation, can access the site fully. One of the big considerations these days is mobile phone access. Most modern phones/browsers can handle some level of Javascript, but equally they often have limitations. Older phones may not be able to use it at all. If your site requires Javascript for things that could have been achieved in HTML, you have unnecessarily locked out those people.

That doesn't mean you can't or shouldn't use Javascript, it means you mustn't rely on it. By all means use it to enhance the site, to provide additional functionality in a quicker and more user-friendly way, but make sure that all the core content can be reached and read without it.

[Stomme poes]

How on earth can any developer not consider accessibility?

It's pretty easy to get into web development and never hear a peep about it, or maybe just a throwaway phrase in a tutorial somewhere. The two problems are that learning resources often make little or no mention of it (I was pleased to see and hear it mentioned often in SitePoint's Simply Javascript book and the online course), and that the web dev community *in general* don't mention it. The Big Names do, usually, but the current crop of Big Names in web dev aren't the semantics-pounding Zeldmans and Meyers but people who are getting known because they push boundaries of what browsers and code can do... bleeding-edge stuff... and people working at browser vendors coming up with new things. Accessibility is usually second place for these people, since if you don't have a product in the first place, you've got nothing to make accessible anyways.

I can't remember where I first heard or read about accessibility in web dev... though it might have been in the intro to Javascript Anthology by brothercake, who is one of the old Standardistas.

Are these accessibility concerns over a decade old?

Some of them are. Some of them aren't. And your users may not have the newest stuff.

People (except IE users) generally have newer browsers, which is why devs have started using things like CSS3 and HTML5 stuff. However, browsers are free and systems often have auto-update.

Accessibility Technology is often retardedly expensive, and costs money to update or upgrade. There are free Open Source options, but sometimes these are either little known in disabled communities (see the WebAIM survey for screen readers... where they asked if people were aware of NVDA, a free screen reader for Windows. The % was kinda low) or aren't quite up to par working with other proprietary software like Eclipse, Adobe products, Office products or many Enterprise business software, because the open source developers have little or no access to these other products, making integration difficult.
I remember Chris Hofstader saying once how Microsoft wasn't willing to give Freedom Scientific (the maker of JAWS and MAGic) the source code to Internet Explorer. So the company basically had to reverse-engineer it. That sounds like suckage.

So while users might have newer browsers, they may not have newer AT. So some of the concerns listed in older resources may still be applicable.

A pretty good example is AJAX. Yes, it seems most screen reader users have Javascript on in their browsers for the same reason most other people do: browsers come with it enabled by default, and lots of users don't even know what JS actually is. Ask Grandma.
However most screen readers use something called a Virtual Buffer. When the page loads, this buffer takes a copy of the page and offers it to the user in a way that the user has many special navigation options and other things they can do. However these buffers didn't automatically refresh if an AJAX call updated part of a web page. Instead the trigger for an update of the buffer was a refresh of the page, which JS doesn't do. So you still have the concern of users not getting the new content. Newer readers (for example I think it was JAWS version 9 that started checking for updates) can deal better with AJAX but the problem of people stuck with older software is there. So you build with that in mind.

Re zoom: there are some of us, like me, who cannot use zoom on many pages. Zoom increases everything. Pictures too. Images become blurry and trying to read next to blurry images gives me a major headache. If I'm using a zoom-only browser like Chrome or Opera, I have to switch to Firefox, who not only offers text-enlarge only, but also I have a toolbar that lets me block all images (there's probably one for Chrome too, haven't looked). For me, text-enlarge is more necessary than zoom, though zoom is better than nothing. As a developer, I test things I build in both. Opera still does zoom the best of everyone who offers it, I think. One nice example is, Opera will switch to your mobile css if your zoom gets large enough on the screen that things begin not to fit. I think this is awesome, and didn't see this on the other zooming browsers last time I checked.

[RyanKing1809]

Thanks for all the advise guys - it's really helpful.

I suppose I'm really trying to push the technology with this website I'm constructing whilst trying to consider every user that would use it. I like to think if my mother couldn't use this website than it is not simple enough but I'm finding achieving a simple interface can involve some complex javascript and regimented layouts - thus the need for px fonts. But I'm proud to say I've just found a script for determining the px height of an em (http://eriwen.com/javascript/measure-ems-for-layout/) which will allow me to have the control I'm after and improve access to those who require AT.

Unfortunately I plan on using some very ajaxy stuff (animations, dynamic content, rich text editing) to push boundaries & create the richest experience possible but it might hinder the viewing experience of those who require AT - especially considering that refresh issue mentioned above. I've come across the term "Hijax" as a form of progressive enhancement and plan on using it for development. Where you create a fully functioning website with html, then using javascript if enabled, hijack the and enhance the existing links and content. And whilst I can make the website degrade gracefully I'm having difficulty dealing with those who require AT and have javascript enabled but script is disabling the AT.

I'd rather not have it come down to choosing between AT and forefront of web technology.

Is there a way to detect AT at all so a different layout could be provided? Maybe I could provide an AT layout my page footer or in the user settings? Something that's not too prominent but can be found if you're looking for it. Any suggestions?

Is there a standard for providing a link to AT layouts? Should there be?

[rguy84]

Ryan, the problem with the script you found is - well it isn't reliable, to be frank. People are still finding issues with determining the browsers correctly. Also it doesn't know the DPI of the monitor, which could cause some issues. I recommend people to design their UI so they zoom to 150-200% without the UI blowing up.

Is there a way to detect AT at all so a different layout could be provided? Maybe I could provide an AT layout my page footer or in the user settings? Something that's not too prominent but can be found if you're looking for it. Any suggestions?

You cannot detect AT at this time. I would be very very careful with following this mindset, some people/groups mark this akin to the seperate but equal argumient. If you are a US citizen, you probably know how well that argument went in the civil rights era. You could implement something like the BBC does for allowing people to customize their experience, http://www.bbc.co.uk/accessibility/.

[Mat30]

It's pretty easy to get into web development and never hear a peep about it, or maybe just a throwaway phrase in a tutorial somewhere...

That seems to be true now, yes. Actually, you have raised a good point about the state of learning resources at the moment, which too often sell shiny but barely-compatible techniques. But for me at least, accessibility was pretty much always on the radar when I was learning (from 2004 onwards). Its value just made sound sense to me. Maybe I learned from good people.

Is there a standard for providing a link to AT layouts? Should there be?

Ryan: I don't like the philosophy of separate low-tech alternative layouts: more maintenance; not certain to work (cookies off, for example); and it suggests that progressive enhancement has either failed or not been employed at all. But if you need to do it, a link around the same place as you would put skip links seems to be the accepted preference among developers. Having never used this method, I don't know what users think of it.

[Stomme poes]

But I'm proud to say I've just found a script for determining the px height of an em (http://eriwen.com/javascript/measure-ems-for-layout/) which will allow me to have the control I'm after and improve access to those who require AT.

I used to use a script by some Polish dude... but I guess I purged the bookmark when I quit using converters (it had "riddle" in the URL) because I was using it to get used to "ballparks"... if I wanted a box to be 400px wide, ~ how many em's would that be? It gave me a starting place, and eventually I got a sort of idea of how so-many em's at my current font-size setting would be a certain size. Not exact, because em's just aren't.

For your AJAXy stuff, it might depend on what you're doing. I mean, if you can just make sure boxes can grow (no set heights on them, not everyone being manually positioned everywhere etc) you could still have flexible units and let the flow do its job. If you're integrating images into this, though, that's one case for pixels: images are raster and in pixels and you can't change that (unless you do SVG or something...).

If you wanted, you could post something of your idea and how it's supposed to work, probably several of us could show you various options and ways to tackle this.

I've come across the term "Hijax" as a form of progressive enhancement and plan on using it for development.

Hijax++.

What you might also want to do is talk to people like Dennis Lembrée, (spelling?) the guy who made EasyChirp (used to be called AccessibleTwitter, but Twitter doesn't like APIs using their name). Twitter is one of those non-degrading, usually inaccessible applications that everyone is using so even if you're blind or whatever you have to use it too because all your friends and family are... so there are lots of apps that try to "fix" twitter, and Twitter is definitely one of those things that people will insist pretty much need AJAX for everything.
If you have a twitter, give him a tweet: @dennisl
He runs? a podcast called Web aXe. You should totally contact him. Or ask him for someone else to take a look at what you're planning and give you tips. Especially if accessibility and how AT and humans and devices work is new to you, you can't expect to be able to build this thing the right way the first time. I have little to no experience building interactive widgets, so I can't help more there. If I were suddenly asked to do so, first thing I'd do is ask some of the guys I know who've been doing this a long while to give me tips and ideas, stuff I know I won't think of myself.

I think once you see various ways that you could do things, you can build this ajaxy-thing better, more robust, gracefully degrading and all that, and accessible.

There are some applications that just don't work or make any sense without intensive AJAX. Those are just harder to do accessibly. If this is what you're building, then a separate, lower-level version might be necessary. Yes, I know exactly what the other guys in this thread mean: usually separate is never equal, and usually forgets to get maintained too.
But for example, while twitter is difficult to use accessibly by itself, their "mobile" version works better. There are more regular server requests, and things are built based on more assumptions of lower hardware capabilities and the such.

So offering such a version isn't necessarily bad. What you wouldn't want to do, as OtherRyan and Mat pointed out, is try to find out who's got some kind of disability and then somehow choosing the version for them. Similar to how many mobile users, who happen to either have great bandwidth at the moment or a new phone with amazing powers of CPU and Javascript and whatever, get rather pissy when forced onto what they consider a "dumbed-down" or less-capable version of a web site simply because the site managed to detect the device was a mobile.

Let users choose, if you end up needing to go the route of two versions. Which is something you usually want to avoid if you can, since that's twice the maintenance.

[deathshadow60]

Ever since I've started posting here I've had @deathshadow60 on my back about accessibility

I will say, that MENTION bbCode is proving quite useful, wouldn't have found this thread otherwise.

And as a result I've been trying to avoid javascript

I never said don't use it; it's don't use fat bloated idiotic libraries on normal pages. If you have 10-15k of plain-Jane scripting uncompressed on a page, that gracefully degrades so the page works without it, there's nothing wrong with that. When you have 50 to 300k of scripting including a 32k compressed library just for some goofy menu animation, tracking software that ignores scripting off users and provides no more information than you should be able to glean from your server logs -- THEN it's a problem.

as much as possible and have been using em heights.

HEIGHTS? I'm assuming you mean font-size, since fixing the heights on elements tends to... well... if it's after the main 'header' area on a page and isn't a fixed size footer for a 100% min-heiht layout... bad things tend to happen.

These articles state that all modern browsers can zoom correctly with pixel-sized fonts

... and do you know what a pain in the ass it is to have to dive for the zoom every time you visit a different site? Now, sure, CTRL+Wheel gets it done, but said zooming also distorts images, often breaks layouts, and if some dumbass made it fixed width zooming often makes it too large to view...

Even with Opera's massively superior zoom that everyone else has pretty much cloned now (and still suck at compared to Opera) it's a pain in the ass to even have to bother doing in the first place JUST because someone is using px. You end up ctrl-wheel ctrl-0 so often zipping around the web -- it's just wasting the users time to where the people who change the default size are as likely to bounce to some site where it's not an issue than struggle with some {expletive omitted} PX based layout.

... and that's what it's about; automatically supporting the users preference! Most all browsers let you change the default size so you don't HAVE to zoom, it's set for your preference. Opera and IE inherit from the system metric, but you can change it in most other browsers too and the people who need it (or just prefer to sit 3' from the display instead of having their nose pressed against it) are probably not going to be happy with the result of zoom unless you REALLY tested what your page actually does when zoomed.... which NOBODY does, if they did NOBODY would be designing the useless fixed width crap! Useless on my netbook, too small for my desktop, breaks when zoomed on the desktop -- yeah, let's just make it useless for everybody except the handful of people with that magical same mix of screen size and font size as the "designer".

and only 1.6% of those using screen readers have js disabled.

... and why focus on just screen readers? How about all the Opera users who only enable js on a per site basis? How about the users like Mallory (Stomme Poes) who run browser plugins like noScript? Handhelds that don't support it or support it poorly?

I mean sure, if you have a page doing something like Google Maps, where JS is the only way to do it, fine.... but that's a very specific and narrow application; 99% of websites out there aren't pulling those types of stunts, yet you still see them blowing hundreds of K of javascript that to be frank, doesn't do anything USEFUL.

I'm not saying don't use javascript -- I'm saying that on most websites javascript should be used with an eyedropper to enhance the functionality and experience, NOT supplant it. That's the mantra that WAS being drilled into us just a few years ago -- enhance don't supplant. Progressive Enhancement == Graceful degradation. A normal website page, like say a page on a forums, blog, normal site for a business -- if it doesn't work without scripting, you're doing something wrong! Ajax or script manipulating CSS to pretend you have framesets topping the list of the broken idiocy.

Do you agree with these articles, in that I can go around setting fixed-pixel fonts

Well, even if the arguments against held water (which they do like a steel sieve -- that's the best kind of sieve you know!) the page by Dave Calhoun then goes on to list legitimate reasons to keep using it...

But his understanding of the "original reason" is 100% fiction. The reason to use %/EM for font sizes is so that if the system metric or browser default font size is different, the page text automatically enlarges to match. That's it. It has NOTHING to do with using the scroll wheel -- it's about supporting 72 dpi handhelds, 75dpi 'big iron' *nix, 120dpi desktop users like myself, and moving forward users of the 144dpi setting that is common on Win7 media center installs -- As well as people who change the default size in the browser on purpose. What screen readers even have to do with the topic is beyond me making his entire "original reason" bit 100% "pulling it out of his backside" -- though he admits that by starting with the phrase "As far as I can tell" -- someone needs to research deeper before opening their yap.

Of course, with StackOverflow being the 4chan of software development, it's no wonder we have people too stupid to even make a coherent statement about it much less understand how it works running their mouths. See the "and their inheritance can be an absolute nightmare" statement, which is one of the dumbest things I've seen said on the Internet given how SIMPLE it is; unless of course you're one of these people that feels the need to declare font-size on EVERY element for Christmas only knows what reason. Good rule of thumb, if it's not a heading, leave it alone! Set your starting size on body, scale headings up from that, where's the problem? The respondents there are just as blissfully unaware of large font/120 dpi users and people who change the browser default as the first article you linked to was.

and using javascript without worrying about it affecting accessibility? Are these accessibility concerns over a decade old?

The thing is it's not about using graceful degrading javascript and the COMPLETE LIE of focusing on nothing but screen readers, as if that's the only thing that matters in terms of 'accessibility' -- forgetting the people who intentionally block scripts due to not trusting them, turning them off due to the bandwidth INCREASE due to things like metered connections or narrow pipes, handhelds still in circulation who can't handle scripting, said scripting possibly making targeting narrow screens with media types harder... I could go on for another two paragraphs about that.

In general, the pages you linked to are by people who didn't understand the point of the technologies they were flapping their gums over, or focused on one narrow reason instead of the big picture where there are dozens of reasons... Just like most people don't get the POINT of HTML... delivering content in a device neutral manner so the user agent can best determine how to show it; playing to the point of CSS -- customizing presentation for specific targets. Hence "separation of presentation from content".

They also started to tread into the 'statistics defense' -- which most always sets off my BS Alarm, since that is one of the 'lame excuses'; I call them "Percenters" -- oh this group is only 1% so who cares, this group is only 5% we don't need to worry about them, Opera users are only 3% so they can go shtup themselves. These people aren't my 'target audience' so who cares what happens when they visit -- until you add it all together and realize you've alienated 100% of potential visitors in one way or the other.

Yes, you can use pixels. Avoiding px was only ever a concession for IE6. IE7 and newer can do full page scaling.

Case in point. No offense, but BULLCOOKIES! It was not just about IE6... IE7 auto-enlarges to the system metric... IE8/newer does auto-adjust the zoom but many people turn that off and set it back to the old scaling so they don't get badly resized images and broken layouts, you can make FF and Chrome default larger, Opera obeys the host OS system metric for pages too! It was NEVER about "just IE6" -- don't know who started that rumor -- probably one of those webkit developers who still thinks "but all computers think in 96dpi". %/EM is about automatically scaling to the users default preference font size WITHOUT image distortions from them being resized and without the user having to even THINK about using the zoom... because for many users if they have to zoom, they'll not even bother coming back to the site. Instant bounce.

Hell, I'd not visit 90% of vBull based websites (including this one) if I hadn't taken the time to add a custom user.css to override it's retarded 13px font sizes. (Thanks vBull!)

Falls into the same misinformation as the whole 62.5% rubbish. That bekaptah nonsense being made by the morons who completely missed the entire point of %/em in the first place -- that being 1EM/100% is NOT supposed to automatically be the same size or ratio to pixels across systems. That's WHY you're supposed to use it... so that it automatically enlarges to the host OS default size and/or browser default size without the user having to play with the zoom on every site-load or browser startup!

... and it's not like %/em is hard? Where in blazes do people get that nonsense? Oh wait, probably from the fixed width layout idiots, Photoshop jockeys with their "not viable for web deployment -- but I can do it in Photoshop" garbage, and a whole host of other layout concepts that should have been left on the cutting room floor (see the wonderful "three across equal width equal height with text inside it in the middle of the main content column" idiocy.)

I mean really, you set it once on body... you scale your headings which are the only things that should really have size changes based off that body declaration... MAYBE make sidebar stuff a hair smaller just so it doesn't distract from the content -- DONE. It's not rocket science.

... and there are cases where PX is your only sane choice -- like when you have fixed size images you need to interact with, or a fixed height footer due to wanting a 100% min-height layout -- in those cases you're best off just using a size nobody is going to get their panties in a twist over being too small... so 14px minimum, 16px or larger better. Just don't do it to the whole page -- menus, headings behind image replacements (and set overflow to cut it off thanks to firefox's sweetly retarded cousin of Netscape 4 behavior)... etc... So long as the CONTENT people are actually visiting the site for is dynamic (%/em), you can play it a bit fast and loose and use px on things like menus, disclaimer in the footer, etc. (though if Gecko wasn't a total retard about adding together %/em, you could use %/em for fixed footers). Remember, window dressing is never as important as what the customer came in the door for... which in the case of a website is the CONTENT.

Unless of course you're dumb enough to try and declare a content area with a fixed height, fixed width, and all the other design concepts that burns the mere notion of an accessible website at the stake, pisses on the ashes, and then a week later decides to defile it's grave.

[Mat30]

+1 to pretty much all of that rant, particularly the bit about statistics, which are a false deity.

The ultimate conclusion to what some devs do will be to take a photo of each web page and replace the whole site with a jQuery slideshow.

Ryan: you're probably reviewing your plans right now and asking yourself whether any parts of what you plan to do with JS and AJaX are actually necessary, and if they are, can they be layered on unobtrusively. If any are not necessary, do they really add anything for Joe User? If not, start asking that.

[deathshadow60]

Oh, just to illustrate 'large fonts/120dpi' -- or as Win7 now calls it "medium" since 144dpi is the new "large"

http://www.deathshadow.com/images/largeFontsMar2012.jpg

Excuse the 1.3 megabyte 5888x1280 screencap... that's two 1920x1200 displays on right, two 1024x1280 portrait on left. Pervasive to ALL applications -- and exactly what %/em are there to obey!

[mcjambi]

i think JAVASCript is so great but it will slowdown your page much ! and when using it too much the browser can be die

[deathshadow60]

And yes, you can use JavaScript. HOWEVER, you still need to think about accessibility. There are actually several potential issues you'll need to be aware of, so here are a couple links that may help.

Interesting links, considering the first is from 2003 (Opera 7, Netscape 7, IE 6... really?) -- Also fun the example of 'good scripting' which is javascript bloat doing CSS' job; though at least it does say you can do it without scripting...

The second is from a source I wouldn't expect to know the first thing about accessibility... what with the crappy fixed width, px layout, lack of scripting off graceful degradation... or the video I can't seem to watch without downloading it... The video problem probably just being Yahoo's "Oh you're a Opera user? Well **** you!" (an attitude a lot of sites seem to have ingrained into them)

Of course that has little to do with the actual subject of the page, it's just funny to see an accessibility topic on a page that is anything but... Not that I've EVER been able to sit through a 'presentation' or video of a presentation without falling asleep. Anybody got a transcript?

[Jeff Mott]

Interesting links, considering the first is from 2003...

Accessibility principles haven't changed much. It feels like you're just trying to pick a fight by objecting to the date.

Also fun the example of 'good scripting' which is javascript bloat doing CSS' job; though at least it does say you can do it without scripting...

Nowhere do they claim that rollovers are a good use of JavaScript. What they actually claim is that this is an example of JavaScript that does not impact accessibility. Again, are you just trying to pick a fight with these silly objections?

The second is from a source I wouldn't expect to know the first thing about accessibility... what with the crappy fixed width, px layout, lack of scripting off graceful degradation...

Whether a page fills your large screen is not an accessibility issue. Neither is using px units. Anyone who wants the page or the text to be bigger can zoom.

The video problem probably just being Yahoo's "Oh you're a Opera user? Well **** you!" (an attitude a lot of sites seem to have ingrained into them)

It looks and works fine for me in Opera. Don't be so quick to jump to conspiracy theories.

[deathshadow60]

Accessibility principles haven't changed much. It feels like you're just trying to pick a fight by objecting to the date.

That was actually NOT my intent on the first one -- to me older articles hold more weight in some respects... at least compared to anything written the past two to three years as the jquery for everything, HTML5 before it's ready or even worth TRYING to use for ANYTHING, and all the other idiocy that is slowly trashing the Internet to the point where it's not as useful a tool (for me at least) as it was a decade ago! It's truly SCREWED UP when the garbage non-semantic table for layout HTML 3.2 nonsense is more useful than most of the crap being vomited up by todays "leading" developers in HTML 5, jquery, and photoshop jockeys who have no business designing for the web in the first place!

Nowhere do they claim that rollovers are a good use of JavaScript. What they actually claim is that this is an example of JavaScript that does not impact accessibility. Again, are you just trying to pick a fight with these silly objections?

Using that as an example, whatever the reason is just bad... waste of javascript; advocating bad code just because it not working scripting off doesn't break the page is still advocating bad coding practice. See the mm_ javascript idiocy that is in every Dreamweaver template. Though again I pointed out they at least had the courtesy to point out it can be done without scripting -- it should have been clearer that using scripting for it in the first place was bad practice.

Funny, you're focusing on the one I had no REAL objections to, instead of the one that's a giant mess.

Anyone who wants the page or the text to be bigger can zoom.

... and your sites are a bounce.... Yeah, and I'm the one trying to pick a fight... Read the posts in this thread much? Understand the point of %/em over px? Statements like that shows you don't. I'd suggest you take the time to READ and maybe COMPREHEND the post before the one you replied to. Then you might understand the context of my screenshot.

It looks and works fine for me in Opera. Don't be so quick to jump to conspiracy theories.

Sorry, but when it's Y! or Microsoft not working in Opera, it's a matter of FACT for me. MOSTLY because they seem to not even be able to declare sizes consistently with their willy-nilly mix of not declaring line-heights, using em heights, with px fonts, so the video is covered by the text below it! Prevents one from clicking on play -- unusual since you usually can't get text to overlap a object tag...

[Stomme poes]

See the "and their inheritance can be an absolute nightmare" statement, which is one of the dumbest things I've seen said on the Internet given how SIMPLE it is;

I'll admit that when I first started using em's, I ran into this now and then, and I've heard plenty of other developers who have the same trouble, but everywhere.

The trick is to use font settings right. And be aware what "1em" means. It doesn't mean 16px (even though on many machines that's about what it'll display as, sometimes). Like opacity (where people also get tripped up... setting 0.5 opacity on a box and then wanting the child to be opaque and trying to set the child to 1.0 opacity... same thing really), em's are based on whatever the parent element is set at, and 1em == 100% of the parent/ancestor's size. Maybe % is an easier unit to start with if you're switching from px layouts and px fonts.

Also, I can't believe I forgot to address this:

Yes, you can use pixels. Avoiding px was only ever a concession for IE6. IE7 and newer can do full page scaling.

All IE's don't do text-enlarge if you set the font size in px. It's just that IE7 introduced (a terrible) zoom feature which some users had to use in order to compensate. But it is true if you try to set the "text-enlarge" in IE, even 9, it doesn't on px fonts. IE believes a pixel is a pixel and does not grow them. Sometimes I think that's true and maybe IE is doing the right thing... well, except now we have "CSS pixels" and with the smart phones it's getting really silly :)

[Jeff Mott]

All IE's don't do text-enlarge if you set the font size in px. It's just that IE7 introduced (a terrible) zoom feature which some users had to use in order to compensate. But it is true if you try to set the "text-enlarge" in IE, even 9, it doesn't on px fonts. IE believes a pixel is a pixel and does not grow them. Sometimes I think that's true and maybe IE is doing the right thing... well, except now we have "CSS pixels" and with the smart phones it's getting really silly

That IE does page zooming is no small detail. Anyone who needs larger text has a mechanism to do so, which is why px units isn't an accessibility issue.

[deathshadow60]

That IE does page zooming is no small detail. Anyone who needs larger text has a mechanism to do so, which is why px units isn't an accessibility issue.

Apart from the broken layouts, fixed layouts that end up too big once zoomed, and it not AUTOMATICALLY appearing larger without resizing everything as large font/120 dpi users expect, not appearing smaller as 72/75 dpi users (admittedly a rarity) expect, not appearing really large as 144dpi media center machines would expect... all without diving for the zoom, and all because "wah, I don't wanna use EM's" -- RIGHT.

Though again, focusing on just IE misses the point -- as if IE was the reason (hell, gecko was called netscapes retarded cousin in regards to %/EM and the host OS for a reason!)... since you can change the default in most every browser, and em is based off the default; whatever that default may be set to -- that's the entire point so people don't have to use the zoom when they've already told the OS "I want 25% larger fonts by default on everything".

As a large font/120dpi user, I lack the words in polite company for what I have to say in regards to "oh you can just use the browser's zoom".

EM is about scaling fonts to the users preference without breaking your layout or resizing images... automatically, without going to the zoom... Just exactly what is this mysterious fictional 'problem' people have with that?!?

[Jeff Mott]

Whether a page respects the OS font size settings is a valid concern and legitimate argument. I never said otherwise. All I've said in this entire thread is that it isn't an accessibility issue. A page that uses px units is still very much accessible to you. One extra click to select a zoom level does not qualify as inaccessible.

[deathshadow60]

A page that uses px units is still very much accessible to you. One extra click to select a zoom level does not qualify as inaccessible.

Except when the layout breaks, ends up too large for the screen (Opera's fit-to-width kinda helps), resizes inconsistently -- I mean really, have you actually USED the zoom in most browsers? It's a disaster... and that can quickly become an accessibility disaster.

Admittedly less of a disaster on fluid or semi-fluid layouts.

[Jeff Mott]

Except when the layout breaks, ends up too large for the screen (Opera's fit-to-width kinda helps), resizes inconsistently -- I mean really, have you actually USED the zoom in most browsers? It's a disaster... and that can quickly become an accessibility disaster.

Yes, in fact, I have used zoom on several sites and in all the major browsers, and the result is nothing like what you describe.

[Stomme poes]

Zoom fails on a lot of sites for me: the sites where, when I use zoom, the page itself (often with two or three or more columns) gets wider than my browser. Which is pretty wide for me, I'm generally a full-screen browser. This entails scrolling the scrollbar back and forth to read sentences.

That's not the fault of zoom, it just has everything to do with how the pages were built. Properly-built pages don't do this with zoom. But when I text-enlarge, I like that the boxes and the images and everything else stay the same. Incidentally, this specific behaviour that I love, Crusty up there really hates (he likes the whole page/layout growing).

That page layouts break on zoom, that IE7's zoom is incredibly craptastic, and that technically zoom seemingly gets a lazy or ignorant developer a Get Out Of Jail Free card with regards to readability... these are not the issue. The OP should avoid using px for his fonts unless he has a Good Reason to do otherwise. To me, a Good Reason can simply be that the OP has both a nasty deadline and not enough experience to build em-font-pages or em-container-pages correctly. Everyone has to learn and most of us learn on the job. It happens.
Another Good Reason would be that images are strongly involved. They're made out of people er pixels, and you can't get around that, so sometimes your font has to also be set in pixels (be aware, various OSes may still not display the font exactly the same way or place or size anyway).

Crusty: Don't worry about Jeff, he's a pro-accessibility guy. He's just stating technicalities.

[RyanKing1809]

Thanks for all your comments guys, you've given me plenty to consider.

So offering such a version isn't necessarily bad. What you wouldn't want to do, as OtherRyan and Mat pointed out, is try to find out who's got some kind of disability and then somehow choosing the version for them. Similar to how many mobile users, who happen to either have great bandwidth at the moment or a new phone with amazing powers of CPU and Javascript and whatever, get rather pissy when forced onto what they consider a "dumbed-down" or less-capable version of a web site simply because the site managed to detect the device was a mobile.

Let users choose, if you end up needing to go the route of two versions. Which is something you usually want to avoid if you can, since that's twice the maintenance.

Thanks for the advice. I can get progressive enhancement working up until a point, but there certain little features (that I'm sure some would consider unnecessary) that I think would improve usability yet could create problems with AT. So I think two versions might be the answer at the moment although it may be considered as one version with handful of functions disabled - maybe that would be easier to maintain. Or maybe providing the option to disable each of these features one at a time would be better.

What you might also want to do is talk to people like Dennis Lembrée, (spelling?) the guy who made EasyChirp (used to be called AccessibleTwitter, but Twitter doesn't like APIs using their name). Twitter is one of those non-degrading, usually inaccessible applications that everyone is using so even if you're blind or whatever you have to use it too because all your friends and family are... so there are lots of apps that try to "fix" twitter, and Twitter is definitely one of those things that people will insist pretty much need AJAX for everything.
If you have a twitter, give him a tweet: @dennisl
He runs? a podcast called Web aXe. You should totally contact him. Or ask him for someone else to take a look at what you're planning and give you tips. Especially if accessibility and how AT and humans and devices work is new to you, you can't expect to be able to build this thing the right way the first time. I have little to no experience building interactive widgets, so I can't help more there. If I were suddenly asked to do so, first thing I'd do is ask some of the guys I know who've been doing this a long while to give me tips and ideas, stuff I know I won't think of myself.

Thanks, I'll look into this.

For your AJAXy stuff, it might depend on what you're doing. I mean, if you can just make sure boxes can grow (no set heights on them, not everyone being manually positioned everywhere etc) you could still have flexible units and let the flow do its job. If you're integrating images into this, though, that's one case for pixels: images are raster and in pixels and you can't change that (unless you do SVG or something...).

If you wanted, you could post something of your idea and how it's supposed to work, probably several of us could show you various options and ways to tackle this.

Thanks, everything's still in its infancy but maybe I'll do this in the not too distant future.