Contents

1. Introduction
2. History
3. Web Standards
4. Structure and presentation
5. (X)HTML
6. CSS
7. Accessibility
8. URLs
9. References
10. Glossary

7. Accessibility

The way I see it, web accessibility is not only about supporting disabled visitors, though making the web more usable for people with disabilities is one of the most important reasons for making a website accessible. An accessible website works better for everybody, disabled or not, and can be accessed by more people with more kinds of web browsers and other browsing devices.

A common misconception is that by making a website accessible, it will look less attractive than, or different to, a website that is not accessible. That is not the case. Accessibility does not need to affect presentation at all.

Here’s an example of how accessibility can help everybody:

A website has a form which can be used to register for a seminar. In the form, you can choose to attend the seminar in one of three cities. Each city name is next to a radio button. If the creator of the form didn’t have accessibility in mind, anyone using a graphical browser has to place their cursor on the tiny radio button and click in order to choose a city. If the developer knows about accessibility and has marked up the labels next to each radio button with the label element, you will also be able to click on the city names to choose a location.

Which way would you say is simpler for anyone using the form?

There are many other considerations, but using semantic, well structured HTML will take you a long way towards an accessible website. To get a basic idea of how accessible a document is, try viewing it in a text-based browser like Lynx to see if the content still makes sense. Again, this is far from the only accessibility check you need to do, but it’s a good start.

Frames

Many web designers like using frames to divide the browser window into several independent parts, each consisting of a separate HTML document. This may be useful for something like an Intranet application. On a public website, however, there are many drawbacks to using frames:

• You confuse the visitor. One of the basic principles of the web is that every page is represented by a unique URL. By breaking this principle, you make it harder for visitors to understand the structure of the site.
• Frames cause problems for search engines. For search engines to be able to index a frame based website you need to provide links to all content pages. Visitors that come to the site from a search engine will also encounter problems, since they are likely to request a document that is missing important parts of the site, like navigational links. Some frame-dependant websites try to get around this by using the file robots.txt to tell search engines not to index sub pages. On other sites, JavaScript is used to send anyone who arrives at the site from a search engine to the homepage. Both of these methods may work if your goal is to get fewer satisfied visitors.
• Frames break bookmarking. Most web browsers can’t bookmark a page inside a frame based website. When you open the bookmark, you will go to the default state of the frameset, which is usually the website’s homepage.
• Printing becomes more difficult. Many visitors will have problems when trying to print documents. Many browsers require you to activate a frame before you can print it.
• Sending links through e-mail becomes difficult. Frames effectively remove the possibility to send links to a page inside the site. Workarounds exist, but add complexity to the site.
• Making the site accessible becomes more difficult. Visitors who aren’t using a graphical web browser that supports frames run into problems. For this reason, accessibility guidelines advise against using frames.

Besides, you are making things harder on yourself. Frames make a website more technically complex and harder to maintain.

Tables

It’s pretty common for people to interpret “don’t use tables for layout” as “don’t use tables at all”. That is not how it should be interpreted. If what you’re marking up is tabular data, it belongs in a table, so a table is what you should use. However, it is important to know that when building data tables, there are many ways to make them more logical and accessible. I explain how to create accessible tables in Bring on the tables.

Forms

Forms are often unnecessarily difficult to use, partly because they are built in illogical ways, partly because the underlying HTML code isn’t using the elements that exist to make forms more accessible and easier to use. The elements label, fieldset and legend exist and are meant to be used. See my article Use the label element to make your HTML forms accessible for more information on the label element.

I advise against using tables to layout forms since forms are generally not tabular data. If you must use a table, make sure the form makes sense and is usable when the table containing the form is linearized.

JavaScript and cookies

Avoid depending on JavaScript. More people than you might think have JavaScript turned off in their browser, be it for security reasons or to avoid pop-up windows. They may also be using a browser which doesn’t support JavaScript. According to TheCounter.com, 6% of web users have no JavaScript. W3Schools.com reports 5%.

In many cases where JavaScript is being used it doesn’t actually benefit the visitor. Of course there are cases where JavaScript can be used to provide a better experience. One example is validating form input.

Note that this does not mean that you should avoid using JavaScript. It does mean that you should avoid making a website depend on JavaScript to work.

The same thing goes for cookies. Do not use cookies in a way that makes the web site stop working if the visitor doesn’t accept them.

Further reading

• Creating Accessible Forms

  A WebAIM article on accessible forms.

• Better Accessible Forms

  An article that goes through the basics of building better, more accessible forms.