Friendly Bit - Web development blog

Projectors: a great accessibility argument

2009-04-03T17:31:32+02:00

So there I sat, at the demonstration of a new website I've been part of building. About 10 people in the room, some of which had never seen the site before. There had been preparations, and we had gone through which parts of the site we were going to present. Only the simple part left…

So the presenter fires up the projector, connects it to his Mac, and looks at the projection. Half the site is outside of the screen. Turns out the maximum resolution is 800×600, and we've designed the site for 1024! People started looking at each other.

"We have to be able to show the site with a projector!", one from the audience proclaimed.

Awkward silence.

I've rarely heard people working with accessibility mention projectors as arguments for accessibility, but it turns out they are great for that purpose. Just look at it like this:

Resolution is often at the very low end, and they get upgraded much slower than regular computers.
Brightness is much lower than on a computer screen, especially at daytime, in a room with bad curtains.
Many presenters move their mouse by looking at the projection, which makes clicking things harder.

Interesting isn't it? Those three just happens to be exactly the same things that we try to optimize when working with accessibility:

We try to avoid having people to scroll sideways, because unexperienced users find that hard to do. A flexible design, that can adapt to different screen widths (within reason), is a great way to accomplish that.
We work hard to make sure that the contrast between page elements is big enough. That way, the large part of the population with low vision (don't forget those that left their glasses at home…), can use the page without problems.
We expand clickable areas of links and buttons, to make sure people with motor disabilities can still use our site.

So, we could just as well have been optimizing the "projector experience" all along.

How did the presentation go? Well, we simply zoomed the site out one step, and continued as usual. You are making sure your site zooms properly are you?

Accessibility as a platform to build upon

2007-02-03T14:00:23+01:00

Two things triggered this post. First a brave participant at the last Geek Meet stood up and asked the question: "Why isn't it ok to require users have javascript enabled?". A few days afterwards I got a lot of good replies to my article about AJAX vs. Flash, claiming that users want multimedia, not plain HTML. To me, those are two different ways of asking one fundamental question: "Is it time we start requiring more from our users?".

HTML: Our history#

HTML has existed for (at least) 10 years now. The first browser, Mosaic, supported HTML and the same documents that where viewable then is still possible to look at in today's browsers. You know those polls that are still made to figure out the percentage of users that support javascript or flash? You don't need those for HTML, everyone supports it. Browsers, Mobile phones, Screen readers, Search engines… Everywhere you turn you have HTML support.

Now. HTML does not have everything you need to make a fully working website. So what you do is add another layer that figures out what the users what and generate HTML for them. It's an easy process and the point is that it does not put any pressure on the user at all, even today you can browse most sites with Mosaic. To me, that's fantastic! We truly have an global format for documents that works everywhere.

Semantic code and web standards did not change the basics, we still use the same header elements that where there from the beginning. What was added was a meaning to each element that had gotten lost in the table-era. Suddenly screen readers could just present a list of headers and know that they presented a balanced view of the site.

But we want more than that!#

In parallell to semantic HTML, Flash and AJAX apps have evolved. They do a good job when it comes to interacting with the user, and interfaces instantly feel more alive. Some developers love them for that.

My thesis is that even though we do want more multimedia there's good and bad ways of getting it. Throwing away 10 years of accessibility can't be the best way? What I want is a way to have both a structured and readable site that is accessible from anywhere, and a site that can give users more interactivity if their browsers support it. Some say it isn't possible, but as a programmer I know that's not true. Based on previous comments I know it is possible to add a flash layer on top of a HTML site; you simply parse the HTML from flash.

You have probably figured this out already but this is what many AJAX apps are doing. They are adding a more interactive layer, on top of HTML. Done right that has incredible consequences for how applications can be accessed by all sorts of devices.

Don't believe those who say accessibility rules out everything else. Use accessibility as a platform to build other apps on top of. Only require more for extras, not the basics.

Judging the technical quality of a site

2006-10-01T00:28:08+02:00

When you look at a website to determine its quality on the code level, you need a different set of metrics than you did some years ago. This article is my attempt at specifying what metrics I use. Have a look at them, do they match yours?

First I look at the validation. Does the front page validate? Do all sub pages of the site validate? If they don’t, what kind of errors are there? While validation isn’t the most important metric, it’s a very quick way to get a feeling of if the coder is “web standards aware” or not. I use the Firefox validation plugin that checks all the pages I visit and puts a little green check in the statusbar if the current page validates. For doing sitewide validation I use htmlhelp’s validation spider and let it loose on the site (check "Validate entire site"). Validation is slowly catching on as a standard tool in the webdev toolbox. Someone who is not using the validator probably doesn't know much about web standards.

While on the subject of validation: don’t forget validating the CSS. There’s a lot of basic errors that the validator finds that only leads to errors in some browsers. The W3C CSS validator might help you fix some of those right away. Before you complain: the CSS validator has a few issues. If you use line-height, you need pass it a decimal number; 1 becomes 1.0, 0 becomes 0.0. Secondly, if you use CSS 2.1 or CSS 3 properties you need to inform the validator you do. Add the URL parameter “profile” with the value set to “css21” or “css3”, and revalidate. CSS errors and whether or not the style sheet is well organized clearly propagates what CSS level the developer is on.

Next I look at the doctype. That single line of information at the first line of the HTML that defines what language the coder is using. Use of Strict or Transitional is what matters most. Most pages that validate as transitional can with very small changes be upgraded to strict. And why not? Strict signals that an effort has been made to ensure that the document separates structure from design. If you know how, there’s no reason not to. At this stage I also check that the doctype is properly set, there’s an IE bug that makes IE render things badly (quirks mode) if the doctype isn’t the first element of the page. Incorrect use of doctype is also a common way to recognize a beginner.

Sites that pass the above code tests get another batch of checks. Is the code semantic? (ie. does the HTML describe the content?) I look at elements, classes, and ids in use. Do they describe the content they contain? Bad sites use class names tied to design. Mediocre sites use general names like “wrapper” or “column2”. Great sites use “copyright”, “invitation”, and “footnote”. Many CMS:es generate design-oriented classes and ids, and only a few reach mediocre. This is one way to see that a site was robot-made.

Another code issue is the content over HTML quotient. For just a few lines of content you shouldn’t have to need huge amounts of HTML. You shouldn’t need 10 divisions just for one header. A high content over HTML quotient signals that the developer knows what he’s doing. An “overmarked” site means that the developer is on the right track but suddenly forgot that content is more important than the code behind it.

One last angle is the accessibility one. How will a screen reader read this site? Is all the content of the site available as readable text? Does the site require javascript when it isn’t needed? A good place to see if someone knows about accessibility (on the web) or not is checking the forms. Fieldsets, legends, and labels: they all tell their story about the developer and his knowledge about accessibility.

A quality site ranks high in all of the above.