Unrestricted Access

Interviews

Trevor Morris

Introduction

Trevor Morris is a 42 year old Englishman, currently reading Internet Product Design, an Electronic Imaging and Media Communications course at the University of Bradford, West Yorkshire. Writes about various things concentrating on the importance of web standards on his weblog trovster.com

Interview

Q1. Trev, these kinds of standards-based makeovers have been in the news recently with Matthew Somerville's makeover of the Odeon website. Matthew took the inaccessible Odeon site and re-designed it for all users. What motivates you to do this kind of work?

A. It's quicker than coming up with a layout and branding of my own! Also these are major corporate sites, presumably receiving a lot of traffic, so their designs have probably been extensively tested and marketed. It's good to apply CSS to real world examples.

I first decided to remake the nokia.com website to gain a better understanding of CSS — its limitations and quirks across different browsers. I also wanted to use semantic mark up to properly represent the outline structure of the page and see if I could remove the site's accessibility barriers.

With vodafone.co.uk, I slightly reworked their design. Their menus have text buried in images, rather than HTML text, so I replaced them with styled, unordered lists. This gives better semantic HTML and the pages load more quickly. Also, I repeated their arrow logo on the links and navigation. In their original design, this logo was incorporated into the different menu images.

It was amazing to see how much redundant code they had on the site. The page weight of their home page is 116kb, which will take about 23 secs to download over a 56k modem. My redesign brought it down to 64kb (over 50kb of which is the images), which will take about 13 secs to download.

Q2. But clearly the original sites hadn't been tested for accessibility. You've taken sites that don't even meet the minimum accessibility standard and turned them into "AAA" accessible sites, even though your 'makeover' looks identical to the original. How do you go about turning them into accessible sites?

A. The easiest way to make accessible websites is to follow the World Wide Web Consortium's (W3C) various web standards guidelines. These guidelines cover semantic markup, the implementation of HTML and CSS technologies and also accessibility issues in WCAG1.0.

Q3. But these guidelines can be extremely opaque. I bet you don't really sit there with your HTML editor in one hand and the WCAG 1.0 in the other. How do you really go about re-designing a webpage? Where do you start?

A. To clarify one thing, I do use a plain-text editor and hard code the entire HTML. This means I'm guaranteed to have valid markup (visual HTML editors often add lots of code, such as redundant <font> tags).

I also mean following guidelines in the most basic form: for example, by using appropriate tags for the content to create semantic mark-up and by closing and nesting tags correctly. It's like using good grammar in a novel: you start a sentence with a capital letter and end it with a full-stop. HTML is the same. For example, the "capital letter" is the DOCTYPE of the page.  Every web page should begin with one because then you can use the W3C HTML validator to check the page uses valid code. If your web pages use semantic mark-up and validate, you are about 90% of the way to creating an accessible website.

Following standards (for HTML & CSS in particular) and creating validated HTML pages which are free from presentation mark-up (like <font> tags), leads to better levels of accessibility instantly. As the code is more structured and concise, assistive technologies used by disabled surfers can work much more efficiently. Then, with the addition of a few extra lines of code, such as "skip to content" or "skip navigation" links, websites can effortlessly attain the highest levels of accessibility.

If you want to see if your own site follows these web standards, you can find a good checklist at Maxdesign.

Q4. Your makeovers, and the creative designs at CSSZenGarden, show that style sheets can give you fantastic control over the visual appearance of web pages yet still achieve the most stringent accessibility criteria. What stops other web designers making the transition?

A. I think web designers fall into three distinct categories:

  1. The "If it ain't broke, don't fix it" brigade: These web designers are usually "old school" and have been in the web business for a reasonably long time.
  2. The ignorant: mostly new people creating a personal site for fun or for a friend, usually as a hobby or for free.
  3. Web-standards zealots.

A lot of "old school" web developers probably feel slightly intimidated by preaching web-standards zealots. A good example of this reactionary thinking is a recent article by David Emberton:

“Standards cronies have now latched on to the disabled - the starving African children of high technology - for leverage. Spend time reading A List Apart, and you'll soon get the impression that accessibility is bigger than cancer, and we're all about to go blind and lose our mouse-bearing limbs.”

http://www.apcmag.com/apc/v3.nsf/0/a569c81864dc4f1bca256e5f001a59c5

"Old school" web developers emphasise that table-based layouts are tried and tested to work in all browsers. It's true that they can be used to create 2- or 3-column layouts easily and they are still used by a huge number of websites. But tables can create accessibility barriers and they don't really work in all browsers: for example, table-based sites often fall apart in voice browsers or mobile devices. Fortunately, many big companies are seeing the light. Macromedia's website is now W3C standards compliant, and even Wired, the poster child of bleeding edge design, is entirely CSS based.

Q5. Given the amount of time you spend looking under the hood at different code, you must have a good idea of the common accessibility barriers introduced by some developers. What common mistakes have you seen? What's the most inexcusable?

A. In my experience, there are three main accessibility bloopers:

  1. Missing alt text attributes.
  2. Text built into images.
  3. Poorly marked-up forms.

The most basic and most widely found accessibility issue is simply omitting the "alt" attribute for images. Every image used should have an equivalent alternative text label. If the image is purely decorative, it should have a blank "alt" attribute (so screen readers will skip over it); ideally, these types of image should be part of the CSS defintion. If it's a functional image, such as a navigation arrow, the "alt" text needs to convey the function (next, back or whatever).

The second major blooper is using images that are just plain text. Often, the text is set in Helvetica or Arial, the most commonly installed fonts in the Western world, so there's really no excuse for this. These are the easiest to fix: just remove the images and use plain text marked up properly and styled to fit into the site. As well as being accessible, another benefit of this approach is that the page will degrade properly in non-visual browsers (such as a mobile phone). This technique also provides better search engine rankings, since Google can "see" real text but not text buried in images.

The third issue, found on a lot of sites, is forms. These are pretty simple to fix if you follow semantic mark-up rules and add place-holding text in entry fields (this provides important information on how to fill in the input element). Designers need to use the right mark-up to link the text label with the text field (<label> in this instance). They should also group sets of controls or entry fields (using the <fieldset> tag). Finally, a <legend> for each <fieldset> gives the user, especially people that use screenreaders, important information about each set of inputs. There's a great tutorial on designing accessible forms at WebAIM.

Q6. We've noticed that following accessibility guidelines also tends to make a page more usable. A good example is adding "title" tags to hyperlinks, which appear as tooltips and help make the link destination clearer. In your redesigns, have you made any changes to meet accessibility guidelines that you feel conflict with usability?

Place-holding text within text entry fields is a potential usability problem, because users need to select it and delete it before typing their own entry. This can slow users down and it can get annoying if there is a lot of fields to complete. But you can solve this with a simple bit of javascript, so that when the user clicks or tabs into the field, the place-holding text disappears.

To remove default place-holding text when the user clicks or tabs into the field, use this generic code:

onfocus="if(this.value == this.defaultValue){this.value=''}"
Q7. Pop-up windows tend to be derided by people in the accessibility community, but there are certain situations where they enhance usability: for example, when they are used like a dialog box in a desktop application, or if they are used to provide some procedural "Help" steps. What's your opinion on pop-up windows?

A. I see very few applications for popup windows on the web. As a user of Mozilla Firefox I am able to open windows in new tabs or new windows when I please and get frustrated when the web developer forces these changes upon me. People comment opening new windows can confuse users, and I can honestly say I've experienced this confusion when I didn't notice a popup. Your comment about help steps, I think, would be more beneficial on the page. If a popup is triggered you would have to keep focusing away from the information to complete the task. A better solution would be to have this information in a prominent position of the page, above the task to be completed.

There are accessible methods to create popup windows. The "target" attribute has been deprecated in strict doctypes and should only be used to reference frames in the frameset doctype. The alternative method to opening new windows, which is becoming a lot more widespread, is to use JavaScript. Most people use this method incorrectly by adding the JavaScript code into the "href" attribute of an anchor. If the JavaScript fails, no window is opened and the link is virtually unusable.

A List Apart have written a great article about making accessible popups. Basically it uses the "onclick" attribute to trigger a simple piece of JavaScript. This means the URL to the page is left in the "href" attribute and if the JavaScript fails the page is opened in the current window. This means users can choose to open the page in tabs or in the current window if a popup blocker stops the popup window. Using the "onclick" attribute with some simple JavaScript is by far the best and most accessible way of creating popup links on the web.

Q8. Final question: Who's next on your list for a makeover? Are there any sites that are visually too complex to re-work with style sheets?

A. I'm currently working on the Trainline website and you can see my work in progress at trovster.com. After that, I don't know, I haven't thought about any more makeovers I'd like to do. The more visually complex the better, so if you see something and think, "You could never do that with standards-based design",let me know!