seanmonstar

Form Accessibility - Try Out Your Own

With web standards being all the rage, and accessibility being a major driving factor in people adopting standards, you might be surprised to actually check out the accessibility of web-sites. After watching a video of a blind user using Jaws, I figured to give using a screen reader a try just to see if I could understand it any better. I ran into a couple problematic areas; what caught my attention first was the use of forms .

When Things Were Right

When a form was built properly, I could easily understand what inputs a form had, and what input I had tabbed to. Quite simply, there were 2 tags the specifically improved the accessibility of the form for my screen reader: legend and label .

<fieldset>    

<legend>Personal</legend>    ...</fieldset>

When I tabbed to an input that was within a fieldset , and that fieldset had a legend , it would tell me. The above would read to me: “Personal grouping.” So if this fieldset wrapped up inputs like your name, telephone, and e-mail address, it would remind me each time that this input was part of the “Personal grouping”, so I knew I hadn’t tabbed to a new fieldset . Good.

<label>    <input name="personal:name" type="text" />    <span>Name</span></label>

For specific inputs, having a label did exactly as we would hope. I tabbed to the input , and it read the label and input type: “Name, text.” It specifically worked with the above example, when the input was inside a label . It would read the rest of the text inside the label .

When Things Sucked

I visited a few other sites that seemed to be using standards, and found that their forms performed far worse. It showed that using the correct structure for forms is actually very important . When a form used a simple paragraph before an input, with no label , guess what happened? Yep, it skipped it. When I tabbed to an input , it would just read me: “Text”. Hey, great. Any text? You got it: poop.

Yea, not good.

Even worse

Even if someone managed to make up information for these fields, or perhaps, say they did have labels on them, one more form feature that screwed my experience using a screen reader: captcha . Some implementations simply had an image above the input, with no alt tag, no possible way for me to ever prove I’m a human being. Minus one call to action.

Try Out Your Own

I’d suggest grabbing NVDA, and surfing your site, and pay attention to your forms. See if the way you made them makes sense to a screen reader. And then visit some of your favorite sites, try out their forms, and compare with their markup. It’s quite enlightening.

Universal IE6 Stylesheet: A Step Backwards

As many have noted, there’s many opinions on how to handle the Internet Explorer 6 monster. For a beautiful web just suggested his solution: one stylesheet to rule them all . It’s completely ridiculous, and I’m suprised to see other professionals agreeing.

A Relatively Capable Browser

IE6, while certainly layout-challenged, can handle basic layout, and still decent color, background, type and image support. People using Internet Explorer 6 are used to web pages looking decent. Websites looking plain black and white with no design all of a sudden will make people think your site is broken (or just sucks). And one principle of web standards is that they shouldn’t think your website is broken .

Sure you could change the text colors, you say. But c’mon, its really not that bad to remove the problematic CSS from IE6. Boagworld did a good job of showing how easy it is to do, and it still looks pretty decent.

The Standards Stance

I’ll be the first to condemn IE6 to the farthest depths of the trash can. I hate the bugger. But as a web developer, I also strongly believe in progressive enhancement , and giving each browser what it can handle.

Sometimes I’m asked to make something look the same in IE6 as Firefox 3, and while I do it (I need to eat), I strongly disagree with it. My boss expects some whining from my side of the office when I’m told. I agree more with Yahoo’s graded browser support .

The plain stylesheet to IE6 turns it into a cousin of Lynx, and certainly under-utilizes the power that IE6 does have. Ultimately, it goes against the point of standards . Why bother at all, if you aren’t going to treat everyone the way they can.

Tables vs CSS? Really?

I’ve seen several big name web-sites point out this argument about whether or not CSS is worse for making web-sites than tables were, and I’m honestly getting sick of it . Some (self-proclaimed?) bigwigs in the web industry are even saying it’s easier to use tables and that’s what they’re going to use for now. I assume everyone knows the reasons for using standards, semantic html, cascading stylesheets, and the like instead of tables. The benefits are enormous. But is it really too hard?

First, No, It’s not hard.

Honestly, writing HTML semantically is super easy. All you’re doing is defining content. That block of text is a paragraph. The first line is a heading. That list is, gasp, a list! That’s the easiest part. Then, after you’ve defined content logically, you open up a CSS file and style away.

Anyone who’s had to transform a design into CSS a few times and knows most CSS properties available knows it’s not hard at all! It takes a couple hours to turn a design into a web-site. But perhaps I’m biased - I get it . I get CSS. What about people who don’t? I can see that, certainly not everyone excels at the same things. So some people might have much more of a difficult time wrestling with the browsers box model. For people like that, here’s what’s up:

Web-sites Aren’t For You

If you can’t understand or work with the new technologies of an industry, then likely, this industry isn’t for you . Can someone honestly call themselves a web professional if they can’t use the tools the web requires?

It’s equivalent to someone learning programming, and asking them to build a game in Java, for instance. If they could not wrap their mind around Object-Oriented design, would it be sufficient for them to say “I’m just going to write one gigantic function, because it’s easier than trying to understand all that Object junk.” …. Fired.

But You Love Web-sites

Perhaps you can’t work with CSS very well, but you still love web-sites. Ok, so you don’t have to leave the industry, but realize what you can and cannot do! If you’re a designer, and you make pretty things, don’t bash CSS because you find it easier to just press Slice in Photoshop. Stick to making pretty combinations of pixels, and let someone else do it.

Or maybe you’re a developer (I’d find this much rarer, but who knows), and you can’t be bothered with the stupid standards of browsers. It’s too non-standard or non-programmery for you. That’s fine. Stick to optimizing the database and give the front-end people quick and efficient queries. Stick to your thing.

But just because something is hard for you, doesn’t mean the proper response is do it the stupid-er way.

When Are CSS Frameworks Good

There are loads of CSS frameworks out there, and plenty more of articles telling you that they are the devil and don’t use them. I agree with these articles as a whole. So what am I trying to say? Frameworks can be good? It depends.

Make You Own

Don’t go and grab any of the gillions of CSS frameworks out there. No, this post is actually about your own CSS framework . Personally, as I’ve sliced a multitude of designs, there’s certain class names and ID’s I like to use. I have a preference on the semantic mark-up for a set of elements. And most web-sites are structured the same, with slight variations.

It’s therefore, quite easy to keep a base CSS file, which I call framework.css, that already has done the things I do every single design. Things like floating 2 or 3 columns together, giving proper padding and margin that I always use.

Style as Generally as Possible

Something else that makes your own CSS really powerful, is trying to use classes (when you need them) to identify elements . And also, styling elements with the least specific rules you can manage . This way, when new html is inserted (by the client, or even yourself) your CSS hopefully already applies. If you made a box that goes on the left, and styled it pertaining to it’s ID, what happens when you add a new box underneath? Were you (or the client) hoping it would be just like the box above it? How much better it would have been if you had been less specific.

Have you built up your own framework that you continue to use?

SproutCore - Standards Stupid?

Steve Webster recently wrote an article about how horribly standards-stupid SproutCore (the Javascript framework Apple used to make MobileMe) is. He kind of has the right mind-set, in that Javascript should be a progressive enhancement to web-sites, and they should still function properly without it.

I agree completely. I feel all AJAX commands that you include in your web-site should do the proper PHP call if Javascript is disabled. Tabs should only contain non-essential information, and the most important should be on the first one, in case it’s not possible to switch between them. But are there exceptions to the rule?

Web Applications - Exceptions?

Now, granted, not all web applications are exceptions. If your application is to be used by the commons, and you’re concerned about people you could leave off, then certainly, make your application standards-smart. Google is a perfect example of this. But must everyone?

SproutCore

Javascript Scarcity?

SproutCore applications are rich desktop-like programs with lots of functionality in them. The majority of the application is written in Javascript. So of course, people without Javascript aren’t going to be able to use it. But how many people is that? All computer browsers come with Javascript. Mobile browsers suck, but would you expect someone to use a rich application from their crappy mobile device? Excepting the iPhone, which does have Javascript in its broswer.

They also seem to have missed the fact that the percentage of users unable to see Flash content is significantly lower than those fumbling around the Internet without JavaScript disabled. According to Adobe’s statistics content published for Flash Player 9 is viewable by an average of 97.4% of web users across all markets. That compares very favourably with the 95% of users who have JavaScript enabled according to w3schools.

There’s a problem with this statement of statistics. Firstly, 2% is not a significant number. But worse, while there is a percentage of people browsing the Internet with Javascript disabled, they all have the easy method of going into options and re-enabling it. And that shouldn’t be too hard, since they had to know enough to disable it the first time. But all those people without Flash have no easy option. You must provide a link to download the proper Flash player, which can be a mess who isn’t so computer-savvy (they exist, and I’m the one the come asking to fix things).

An Enhancement?

Here’s why SproutCore tends to be an exception: The application is written with Javascript in mind. It’s written to use Javascript. It’s saying to the users: Hey, you want to use Application Awesome? Cool. It runs in Javascript, so just enable that baby and awe your mind.

If someone doesn’t have Javascript enabled, telling them to enable it to use your Javascript Application is not a sin. It’s much more of an ordeal to write the same functionality in a bunch of dynamic pages, incase the user doesn’t want to turn on Javascript. SproutCore isn’t used to make enhancements to your web application. Ajax-y form submittals are enhancements. It’s OK to make the User be semi-proactive by clicking Enable Javascript. No one complains that web-sites require a Flash plug-in, or that Java applets require a Java Virtual Machine.

Disclaimer: Most likely, you’re application has Javascript as an enhancement, if it has Javascript at all. Do not use this article as a reason to shoot standards in the face. This is directed at those rare applications that are built in Javascript.