Podcast 27: Pragmatic accessibility
Posted in Podcast on: Monday, March 13, 2006 by Paul Boag
How do you make sure your site is accessible while avoiding “design compromises” and ensuring a healthy return on investment? This episode of boagworld.com focuses on applying accessibility theory to real world scenarios.
Podcast: Play in new window | Download (24.7MB)
Main feature: Pragmatic accessibility
Back in episode 10 of boagworld.com, we looked at the basics of accessibility. We asked why accessibility is important, how it is measured, and the theory behind its implementation. However, accessibility theory can often be leagues apart from the everyday reality. In the real world, accessibility has to find its place alongside design and marketing requirements, technical constraints, usability considerations and business drivers. This week’s show looks at how accessibility works in practice. We encourage web site owners to move beyond simply conforming blindly to WAI standards but rather examine the needs of their target audience and developing the right accessibility solution for them.
Accessibility resources
In our web resources review section, we look at what help is available online for those interested in improving their sites accessibility. In particular, we highlight two incredibly useful resources:
Accessify.com
Accessify.com is the leading site on web accessibility. The site has a friendly forum, which is a great place to start for those exploring accessibility for the first time. It also has some excellent articles but probably most useful of all it has a brilliant tools section, which really helps overcome some of those accessibility barriers.
Accessibility business plan
The W3C have produced a compelling business plan for improving your sites accessibility. If you need convincing about the business benefits of accessibility or have to convince your manager then this is a great place to start.
Techno buster: XHTML vs HTML
This weeks techno buster is more "techno" than "buster" as it discusses the advantages and disadvantages of moving from HTML to XHTML. However, in the tradition of boagworld.com we do make a point of explaining what the difference is first!
21 Comments
Comments are for the discussion of this post. If you have other questions / comments then post them to the forum or send me an email
Here’s an Accessibility podcast: http://webaxe.blogspot.com
If you want to have text in textboxes, but help with accessibility too, you could try using Jeremy Keith’s disapearing/reapearing text in textboxes script.
If you want to get a link to Headscape (or at least Boagworld) from the BBC, this could be a good time to try – the list of BBC shows also podcast has just increased a lot. There was a discussion about podcasting on Woman’s Hour today. Perhaps you could get an interview, and thus a link, on another program.
:-ppppppppppppppppppppppppp @ Paul
@ fellow Mac developers – Remember testing for IE [spit spit] is the LAST thing you do once you’ve got everything working in a real, compliant browser. At that point a sad friend or family member who has nothing better than Windows comes in handy.
Hey Paul & Co,
Thanks for the podcast. I am one of those who’s just recently quit using tables. It was a matter of being a grasshopper to the wrong master.
Thanks for beating CSS over my head. As soon as I get this all sorted out, I imagine it will be a life changing event.
~Shana from Nebraska, US
Hi Paul,
Just listened to your latest podcast.
One of your listeners asked a question about testing in IE6 on a Mac.
Mac users do have another option you didn’t cover. There’s a free PC emulator called Bochs which you can set up on your Mac.
It’s a bit hard to set up, compared to Virtual PC, but it does work. You can then install Windows XP and hey presto – Internet Explorer 6 on your Mac!
Or you could look in your local paper a just buy an old PC for £50.
BTW – Macs aren’t expensive .. they’re just very well speced. If you buy an equivalent PC the price of an iMac is fairly similar to a PC. Plus Macs don’t have milliions of viruses.
;o)
Before I comment… your podcast is great, I look forward to each and every one.
That being said, I have MANY issues with your “techno-buster” this week.
HTML is a language that follows the rules of SGML. SGML is very generic and allows for lots of options. A good example is that you can omit the closing paragraph tag in HTML (which is a feature of the SGML spec).
XHTML is a flavor of HTML that is XML complient. XML is rooted in SGML, but was simplified greatly, removing flexibility in favor of ease of learning.
Why use XML (and XHTML) – SGML is complex, so tools are expensive or specific to a language (like HTML). XML is much easier to write tools for, so tools are abundant, and available in every language. So the answer is this, in my opinion, is that XML formats make it easier for programmers to automate certain tasks because many more tools are available.
What is required for XML… the DocType is NOT required for a well-formed XML document, as you had stated. XML has certain requirements, but this is not one of them.
Well-Formedness vs. Valid XML… You confused these terms. A “well-formed” XML document meets the requirements of the XML spec (no leading whitespace before the document root/declaration, properly nested tags, quoted attributes, etc.). A “valid” XML document is one that conforms to a given XML language, in this case XHTML.
Ummm… I these were the only issues I found. I’ll have to play it again to be sure :)
Well I am sure that would have been a much more accurate if not clearer description! The techno buster section is supposed to make things more understandable! lol. However I humbly bow before your superior knowledge ;)
Hello Paul & Marcus.
Regarding how different browsers render CSS, there is a better way (in my opinion) of handling browser detection. From what I’ve read, conditional comments only work in Internet Explorer, and require the maintenance of multiple stylesheets describing the same design, since they only work in html documents. Either that or put the css in the page header, which defeats the caching benefit of an external style sheet.
What I’ve been doing lately in my programming is generate css files dynamically using PHP. PHP doesn’t have to generate a content type of text/html. You can change it to any content type, including text/css. The top of the page just needs :
<?php
header(‘Content-type: text/css’);
?>
From there, you can detect http header information and retrieve the user-agent. That will give you not only the browser, but the version as well. Quite useful as the release of IE7 breaks many CSS IE hacks.
Next, compose your CSS as usual. When you encounter a style that shows differently among the browsers, throw in an if-else for the different cases. Save the php document and link to the .php file from the web page just like a .css file.
I’ve seen some samples of ASP doing this as well. So, as long as the webhost is capable of server side scripting, it’s possible to create a single stylesheet that’s generated dynamically that handles browser detection instead of relying on the html document to do the check.
Here’s a small writeup about it and the code techniques I use to do it:
http://www.digitalbonsai.com/phpstyle.php
Can’t wait for the next podcast.
-Lu
Paul, I’m a little upset.
In reference to a mac, you said “…Get a proper PC”
What does that mean?
I’m not going to go on a rant here because personaly I think you were drunk. lol . Really, you said some off the wall stuff this ep.
No hard feelings, tho.
Luis, I appreciate that conditional comments only work in Internet Explorer, but that is what is good about them: you can make a style sheet that you know will only work in IE (or some other browser that realllllly wants your page to think it is IE).
I’m a little concerned that the php browser detection might end up like the bad old days of the “Browser Sniffer” code.
Conditional comments mean that you can work around an IE bug without having to worry what other browsers might be affected (especially as you can set which version/versions of IE will “see” the conditional comment). Seeing as quite a few of the bugs are IE based anyway, conditional comments could be enough to get the site looking as it should.
The best solution would be for every browser to render things properly, but I guess they all have their own ideas about what “proper” rendering would be anyway!
Ed, best solution indeed is to have standard browser rendering, but until then, we need to check for browser types.
I agree that Javascript based browser sniffing isn’t the way to go. They’re unreliable and Javascript can always be turned off. The thing with php stylesheets is that it happens at the server, instead of the client. Also, they’re getting their information from the http headers (user-agent) instead of detecting features of firefox, ie, safari, etc to determine browser type.
An example of how javascript browser detection breaks is in AJAX. I used to detect for ie if I pick up an ActiveXObject instead of an XMLHttpRequest. Doesn’t work in IE7 now as ActiveX has been dropped and now works off XMLHttpRequest.
But with PHP reading the user-agent, you know what browser is being used directly instead of hacking it. I think it may also be how conditional comments retrieve browser type/version information as well.
The problem I have with conditional comments is that they only work on an html doc and only work for IE. Sometimes I find CSS rendering differently between Firefox and Safari, and I need to differentiate between those two. So, instead of having a Safari, a Firefox and an IE stylesheet, I just have one with conditional statements within them. And that one stylesheet delivering the appropriate style information to each browser without relying on hacks.
Hey, mac users aren’t stuffed when it comes to testing on “IEWin 6.crappy”.
Try out http://www.browsercam.com/ – you have to pay for it, but it’s a great solution for those of us with the common sense to use macs!!! It’s also good for conscientious PC users who want to test cross browser/platform AND!!! you can use their remote access facility to test functionality.
I should be getting a commission for this… nevermind.
How I love making rude mac comments :) What a reaction I get every single time! Its only because I suffer mac envy ;)
“But with PHP reading the user-agent, you know what browser is being used directly instead of hacking it”
And there is no way of user-agent-spoofing with the PHP solution?
/////
There is a BBC article on an accessibility organisation, the Usability Exchange, which people might want to check out.
“And there is no way of user-agent-spoofing with the PHP solution?”
If you user is spoofing their user agent, do you really care? Sure, I could use Opera, and have Opera pretend to be IE… but if I don’t get what I expected, I am the one to blame. I don’t think you can expect a developer to develop for that possibility.
“If you user is spoofing their user agent, do you really care?”
Practically there’s not much you can do in that situation, but isn’t that what brought down the JavaScript browser sniffing?
Do you really want to be updating your CSS every time a new variation on a browser comes out that doesn’t render your site as you wish?
(By the way, I do actually quite like the php css idea, but just asking some questions to get some things clear about it.)
And in terms of object detection – I think if you are detecting an object, you should only do so to see if that object is there, rather than to infer something else about the browser – as shown with the XMLHttpRequest and IE7 situation.
I think the problems with Javascript based browser sniffing is that it relies too much on the client and whether or not their browser can do it if Javascript is enabled at all. Turning off Javascript is much easier to do than spoofing/cloaking your user-agent.
It’s just as easy to update your CSS with new browser versions that deviate from expected interpretation. You would have to do that anyway with separate stylesheets to cover the variation, right?
This may be restating some of what I typed in a reply earlier this morning (that didn’t post automatically because of manual approval ?), but I think if the fix for inconsistent browser style interpretation can be resolved at the server level and not rely on the client, you can get more reliable behaviour. Not to mention greater precision in the fix. “You can stitch the wound or amputate the limb”. You can fix the exact piece of css information that’s causing trouble, or you can create a completely different stylesheet that you have to maintain. That seems messy to me (please forgive the associated visual). Also, conditional commenting only detects if the client is IE or not.
The only drawback I can think of from using dynamic css is requiring the web server to support scripting, whether PHP, ASP, etc. But as professional developers, we should all realise the importance of server side scripting. If we maintain our own servers, PHP is free as is Apache server on Windows, OS X and Linux based servers. If we use a third party webhost, there are many inexpensive services that provide scripting as part of the package.
As for object detection, you’re right. I had to fix something of mine that had that issue last night. Something I forgot to test in IE7 for.
“It’s just as easy to update your CSS with new browser versions that deviate from expected interpretation. You would have to do that anyway with separate stylesheets to cover the variation, right?”
Right, and fair enough, although there is something to be said for the idea of a single file making changes, which can then be removed when no longer needed.
“manual approval?”
I think as long as you type the Security code, the post should show up.
“Right, and fair enough, although there is something to be said for the idea of a single file making changes, which can then be removed when no longer needed.”
True, and if that’s the method someone prefers, that’s fine. But then you can still use server side scripting to do the detection and select among the stylesheets. It would just be in the html instead of the style.
And I think the whole manual approval thing happened because I was submitting from a Palm device this morning instead of my desktop. Maybe something didn’t transfer over correctly. *shrug*
Oh, one more thing about dynamic css… It is technically more work for the server, but the browsers should cache the stylesheet anyway. So it’s more work once, but after it’s cached, it shouldn’t be an issue. I’m still looking into browser caching php information.
For Mac users, there is now another option for testing on Windows: Install Windows on your Mac. This would mean obtaining a copy of Windows XP, and probably having to reinstall your Mac OS too, but it is something to think about!
I think this is still an important topic, and deserves more exposure. Accessibility is becoming a highly important field of design, and it’s important for designers to catch on. The problem is that most designers are not disabled themselves, and so only create what they *think* accessibility is… or what they think will work. It may end up that it is not practical at all for the users of the sites.
Certain accessibility issues need to be adressed by the browsers themselves, as well. If a browser could find something that really works, it would probably skyrocket that browser in the browser wars.