Skip to page content or skip to Accesskey List.
Search evolt.org
evolt.org login: or register

Work

Main Page Content

Accessibility Inherent in Good Markup

Rated 3.56 (Ratings: 10) (Add your rating)

Log in to add a comment
(9 comments so far)

Want more?

 
Picture of TonyHaddon

Tony Haddon

Member info | Full bio

User since: March 21, 2002

Last login: March 03, 2006

Articles written: 1

As a new member of evolt I'm writing this, my first article, inspired by Aardvark's "The Wrong Way to Use CSS in Page Layouts" article and the comments that succeeded it.

The article itself was great, and actually surprised me by highlighting the high use that is made of the CSS positioning feature, something I was quite ignorant of. In commenting on this article, some people bashed WYSIWYG editors which used absolute positioning, promoting hand-coding as the only viable option (my corner, admittedly). Others defended them, pushing the idea that they do indeed speed up layout build when used by designers who (hopefully IMHO) hand those layouts over to a coder for cleanup. The comments led me to thinking about what many people seem to have missed.

We all want our websites to look good. The concept of the internet is nowadays wholly integrated with the concepts of design and usability. We must not forget that it's core purpose is the presentation of information. And because of the way we go about building our websites, some people are missing out.

Consider the internet from a blind user's point of view, for example. They might use a screen-reader. Most of these read the source HTML of the layout file to interpret a page. If a site uses absolute positioning to lay out bodytext, how is a screen-reader to distinguish between what is at the top of the page and what is at the bottom? Perhaps some of them will examine the pixel coordinates and read in order of the lowest x or y value, but then - what is a heading and what is not? The screen reader would be baffled by a tagging scheme such as:

<span class="boldwhite17">This is my point.</span>

Whilst it's much clearer to use:

<strong>This is my point.</strong>

The <span> tag (and similarly the <div> tag) is not descriptive of its contents. Get rid of it. Use the old-fashioned semantic tags (<b>, <i>, <strong>, <em>, <h1>-<h6>, etc.) because they are descriptive of their contents. You can still style them with CSS after all and change them to any colour or size you want.

In terms of positioning — learn to use tables properly. It just takes a bit of practice and if you get stuck, by all means use DreamWeaver to build them. I know myself that when the rowspans and colspans get to be a little too much, I will. Just clean up after it, there's a good web professional. Or else just keep your layouts simple. Less is more, as my design lecturer used to say.

Absolute positioning isn't supported by so many browsers, either. And some do it really badly. NS6 once positioned my image exactly where I wanted it, but at the point where the style tag code was read (just after the body tag) the dimensions of the image were imposed on the space where it would have been, as if had been just an isolated <img> tag. Rubbish!

I have to say I'm as guilty as the next man of tables chock-full of images with image links nestled up flush together (If you're going to do this, for heaven's sake fill in the alt attribute for links!). That's because I've got a boss who's a designer and learned his trade in the print-and advertising industries. So in the past we've collaborated on some nice looking, but bandwidth-beastly websites.

I was as ignorant as he about most of this until a couple of government requests for tender fell on our desk accompanied by a whole booklet on government website accessibility guidelines. Although I must confess to being not entirely au fait with all the points it made (something like it's shunning of more than two columns in tables — boo!), it did provide a good deal of food for thought.

One of the requirements it held was that the government site be Bobby approved — this being an internationally accepted accessibility standard with a very bad logo. Having visited aardvark's portfolio site in search of inspiration, I noted the bobby badge there (along with all the other ones, which led me to liken it to the sleeve of a boyscout's sweater — ho ho), so perhaps he'd care to comment on this and enlighten us further on accessibility issues.

All this does serve to undermine a lot of the things I love about the internet, Flash movies, for example, are a big no-go area for screenreaders. Markup only serves to contain a Flash movie like mounting a picture on board. Maybe in time these things will change.

More than likely HTML, even XHTML will be replaced, perhaps by SVG (Scalable Vector Graphics — almost like a Flash markup language) or something similar, as the chief authoring language of the web, where we can draw circles without impunity, draw typefaces with vectors and still allow screenreaders into markup to pick out paragraphs and headings. One day — when all browsers agree on how to parse a layout consistently. Wow. Wouldn't that be something!

So in the meantime let's not go about building our pages without their wheelchair ramps. The Internet allows people who can't read newspapers or magazines to access their online counterparts via their screenreaders. Let's not ignore their needs and allow the internet to accentuate a disability. The lads who built HTML knew what they were doing and those tags have a reason for being there. Use them.

Fascinated by the building of websites from the multiple perspectives of design, technology and usability, Tony worked on websites as a hobby for four years before somebody actually gave him a chance, as in a job, in a Dublin-based Internet and communications company. In 2004, he left and now runs his own business.

http://www.tonyhaddon.com

Other tags and attributes can help too

Submitted by riffola on March 29, 2002 - 01:20.

ABBR and ACRONYM tags can be used to make things more accessible to screen readers, and the title attribute can also be used to enhance the usability.

login or register to post comments

Constructive criticism

Submitted by skunk on March 29, 2002 - 03:40.

That was a good article (well written, plenty of excellent points) but I'm afraid I'm going to have to disagree on quite a lot of it...

Firstly, well designed and properly used CSS (used for layout) should be a great deal more accessible than a corresponding table layout. With tables, the order in which content appears in the HTML code can end up being very loosely related to the layout of content on a page (thanks to rowspans, colspans and the like). Table layout also encourage all kinds of dirty "hacks" to get content looking just right - fine for browsers, but what is a screen reader meant to make of several nested tables?

CSS layout on the other hand allows you to lay out text in the HTML in the order that makes most sense - you can then apply the CSS to "shape" it into your design in the browser. This is the primary benefit of CSS - the ability to seperate content from presentation.

A good example of this is www.alistapart.com - CSS is used for layout, but if you view the HTML source of the page the order in which content appears (and would be read out by a screen reader) makes a great deal of sense. This is also important for degreading gracefully for older browsers that don't support CSS.

I agree completely with your call to use descriptive elements (h1, strong etc) over span and div tags when applying styles to ensure the meaning of the content is maintained.

As far as SVG replacing XHTML goes, I don't personally see this happening. SVG is a fantastic language for detailed control of the appearance of images and text, but this becomes a major disadvantage when authoring for the web. Documents on the web should use XHTML simply because it provides structural markup (with CSS defining how things should look) - this allows alternative browsers / platforms (hand held devices for example) to display web content in the way most suitable for that platform. Getting a mobile phone of the future to display a page written in SVG would be a waste of time (the screen would be too small) but an XHTML page could be rendered easily by analysing the document and stripping out any non-essential content (or by using an alternative stylesheet specially designed for mobile devices).

login or register to post comments

Thank you !

Submitted by notabene on March 29, 2002 - 04:05.

I've been advocating exactly that on the intranet I've been working for for several months.

You made the point so much clearer than what I came to express. Bookmarking right now. ;-)

login or register to post comments

WAI Guidelines

Submitted by OKolzig37 on March 29, 2002 - 10:04.

I think, in spirit, much of what you say is in agreement with the WAI (Web Accessibility Initiative) guidelines, except for the bit about using tables instead of CSS for layout.

The WAI Guidelines specifically recommend using CSS to control layout and presentation (Guideline 3.3). The reason seems to be what happens when tables have to be linearized by a screen reader. In a standard two-column layout (with navigation on the left), a screen reader will read the navigation first ("About Us...Locations...Contact Us...", etc.) and then read the content of the page. With CSS, you can position the content in the same fashion, but place it in the code so that the content is displayed before the nav (allowing screen readers to correctly read the page and allowing most browsers to correctly view the page).

--Ben

login or register to post comments

the div tag

Submitted by luminosity on March 29, 2002 - 19:22.

It seems that you're recommending using table tags over positioning using CSS, and yet you recommend not using DIVs? I can agree with the sentiments about taking spans out, however divs can be very important for ordering your data. If you do use divs, such as a div for menu and a div for content, you can have pages that lay out well with css, and degrade fantastically without it - something there is no other appropriate tag for.

Maybe you should change the sentiment to 'get unneccessary div tags out of there'. And the same for unneccessary tables. If you're recommending losing divs for their lack of structuralness, then you should definitely be recommending avoiding tables for layout purposes too - after all, while divs impose no structural meaning on their content, apart from that it is different from the rest of the page, a table specifically implies tabular data - not layout.

login or register to post comments

Semantic tags

Submitted by asjo on March 30, 2002 - 14:23.

One flaw: <b> and <i> aren't semantic tags (bold, italic). They shouldn't be used; rather <strong> and <em> (strong, emphasize) should be.

Best regards,
Adam.

login or register to post comments

Thanks for feedback

Submitted by TonyHaddon on April 1, 2002 - 23:06.

Good to see my ideas interested some folks. Thanks for the good responses. I'll be thinking about those other ideas. My apologies for the <i>,<b> slip-up. I'm still quite new to this - but picking up things all the time, thanks to sites like this.

login or register to post comments

Thanks for feedback cont....

Submitted by TonyHaddon on April 1, 2002 - 23:10.

I prefer tables for layout because CSS isn't yet a reliable cross-browser recommendation. I pointed out a couple of my major beefs with it (or rather its interpretation by browsers) in the article, I think, such as inconsistent positioning and lack of cellspacing attributes in some browsers.

login or register to post comments

..

Submitted by skunk on April 2, 2002 - 04:31.

Fair enough then :) CSS support is finally getting to the stage now where it's a valid replacement for tables though (if only IE didn't keep breaking the box model).

login or register to post comments

The access keys for this page are: ALT (Control on a Mac) plus:

evolt.orgEvolt.org is an all-volunteer resource for web developers made up of a discussion list, a browser archive, and member-submitted articles. This article is the property of its author, please do not redistribute or use elsewhere without checking with the author.