skip to main content

Jim Byrne Accessible Website Design Glasgow for The Third Sector, Voluntary, Charities and Not for Profits

Accessible, Responsive Website Design
Jim Byrne Web Designer

Structure your menus by marking them up as lists

Published: November 3, 2014

A navigation menu is – if we are speaking structurally – a list.

I still see websites that don’t markup their navigations links as lists; I guess the reason for this is that designers don’t want to have ugly big bullet points littering their menu’s, or seemingly uncontrollable margins throwing out their carefully crafted layouts.

Is it possible to use the correct structural markup, and still make your menus look the way you want them to?

The simple answer is yes; you can use CSS to style lists to look more-or-less any way you want.

First, undermine your previous assumptions by visiting the Listamatic website to see examples of different list styles (with the CSS used for each).

Then visit Mark Newhouse’s Taming Lists tutorial to learn how to make your own.

And finally – if you can’t be bothered learning how to do it yourself – have a look at Accessify’s List-o-matic – where you fill in a few forms, and the List-o-matic tool does all the hard work for you.

Why is this relevant to accessible web design?

Using the appropriate markup for all the structures in your web documents is the first step towards making them accessible; web pages need to be accessible to the ‘user agents’ people use first, before they can be accessible to the people themselves. Using valid standards based markup means you have the best chance of your pages being understood by those intermediate ‘user agents’ (usually that means computers and web browsers).

Links

So how do you add character encoding information?

Published:

For HTML 4.01, you can indicate the character encoding in the head of your page using the following meta tag:

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

ISO-8859-1 (commonly called Latin 1) is the default characters set for HTTP .1.1, and indicates a set of common English characters. Generally this is the most common character set indicated in web pages, and is likely to be the one you will use.

Creating valid HTML is one of the most important steps you can take when designing accessible websites. If you do not provide the appropriate character encoding this could lead to characters in your page not displaying correctly, which of course will have an impact on the accessibility of your content.

Links

Make your pages validate when they include urls with ampersands (&’s) in them

Published: August 19, 2014

At some point you will run your web page through the W3C validator and get the error, “unknown entity section”; due to the presence of ampersands (&’s) in page link urls.

The validator assumes that this is an error because it expects an ampersand to be the beginning of an entity.

I had this very problem myself when creating the weblog links for my own CMS. For me the solution was simple; I just get the CMS script to turn all ampersands into their equivalent entities.

Unfortunately it is slightly more work to manually replace all ampersands in a page, but if you want your page to validate it is a chore you will need to attend to:

For all urls in web pages that contain ampersands, i.e., replace each ampersand (&) in urls embedded within your pages, with the equivalent entity &amp; , e.g.,

http://www.mcu.org.uk/showlog.php?weblogid=74&contentid=1

Needs to be modified to,

http://www.mcu.org.uk/showlog.php?weblogid=74&contentid=1

Another validation problems solved.

CSS accessibility: is markup dead?

Published: August 8, 2014

Increasingly, Web designers are ‘doing the right thing’ and switching to CSS for presentation and layout. This move presents its own challenges (do I hear the words bugs and workarounds), but we are clearly heading in the right direction. In most cases the move to CSS will result in Web pages that are more accessible than their HTML only counterparts – but it is not all sweetness and light. This move towards greater use of Cascading Style Sheets is starting to throw up some important accessibility problems peculiar to this new practice. It is one of the more important of these problems that I have chosen to highlight in this article.

Using CSS to mimic proper HTML Markup

How do you know what this article is about ? Well for someone intelligent like yourself, with, and I’m guessing here, a 100,000 million brain cells, that’s an easy question to answer . All you have to do is read the heading at the top of the page: ‘CSS accessibility problems: is markup dead?’. Yes, it is clear – this article is about accessibility problems related to the use of cascading style sheets.

Now if you looked at the source of this Web page you would see that I have also tried to accommodate the rather less intelligent Web browser you are using by taking the time to add appropriate markup to the heading text, i.e. I have used the Headings element (in this case H1). Your browser knows about this element and knows that headings require a particular set of style attributes.

And because I care about presentation – and I would rather you saw something different from the default style – I have used a style sheet with the following rule to make the heading look a little nicer:

H1 {
background-color: #000033;
font-size: 1.35em;
font-family: arial, helvetica, verdana, sans-serif;
color: #ffffff;
padding: 1em;
}

The style of this heading may not look exactly the same in your Web browser as it does mine, but you can still tell that it a heading by its position on the page and by how it looks. Some of the clues you have used to work this out are a result of the way your Web browser has processed the page; your browser ‘knows’ that if it ‘sees’ text contained between the <H1> and </H1> tags respectively it should make the text bold, a bit bigger and put it on its own line.

This rather simple idea of adding labels to the text on a page to say something about their function is important for a whole host of reasons. Not the least of which is the following general notion. If I mark up a document using a set of widely known and commonly accepted set of tags – collectively called HTML tags – I am saying to any Web browser capable of processing the page, “this is a Webpage, not a MS Word, rtf, PDF document or a computer program, photograph or image”.

A properly marked up page has all the attributes that have made Web pages so popular since Tim Berners Lee made the first one back in 1990, i.e., easy to create, display on any hardware platform, and accessible from any internet connected device with a Web browser installed.

If we don’t markup documents using HTML we don’t have HTML documents – and we lose any usefulness that giving structure and meaning to a document bestows. That is why the ever-more-common use of style sheets to mimic proper structured markup is my number one CSS accessibility complaint.

It is disappointing that lack of appropriate markup has become one of the most common problems I come across when carrying out access audits of Websites. Headings, paragraphs, quotes, lists and inline elements such as strong and em are being replaced with neutral or innappropriate tags, and merely styled to look like headings, paragraphs, lists or inline elements.

An example should help to illustrate my point.

A very similar ‘heading’ to the one at the top of this page can be created using the neutral ‘SPAN’ tag with appropriate style sheet attributes:

<SPAN class="topheading">Using Cascading Style Sheets</SPAN>

.topheading {
background-color: #000033;
font-size: 1.35em;
font-family: arial, helvetica, verdana, sans-serif;
color: #ffffff;
padding: 1em;
}

And here is how it looks – assuming you have a CSS aware Web browser.

Using Cascading Style Sheets

It looks like a heading, feels like a heading (eh!) and walks like a heading (now you are just being silly Jim), but it’s not a heading it’s just a bit of styled text. That is, it is just a bit of text that looks like a heading when displayed on a computer monitor. But why worry? If it looks like a heading – surely it is a heading?

Why does it matter?

If we lived in a world were everyone accessed the great riches of the World Wide Web by sight alone – then it would not matter. In such an environment – if it looks like a heading it is a heading, but we don’t live in such a world. Web pages are processed by programs, rendered as audio by speech enabled browsers and made physical by refreshable braille displays. On these devices is the above still a heading? – or is it just another piece of text undistinguishable from all the other text on the page?

Let’s look at three good reasons showing why using proper markup is important.

Reason 1. A blind person using a Web browser like IBMs Home Page Reader.

As a sighted reader of a Web page I can quickly get an overview of its contents, and decide what bits I am interested in. One way I do this is by a quick scan of the headings on the page. This is nothing new, nor is it unique to the Web. Just think about the way you look through a newspaper; you turn the page, scan it for interesting headlines, and focus in on the stories or features that catch your eye. Like me, you probably take for granted your ability to quickly sift through the quagmire that is written text hoping to find those little nuggets of life enhancing information. But how do you accomplish this important task if you are a blind or visually impaired reader, how then do you get an overview of a Web page?

Manufacturers of speech enabled browsers address this problem by extracting all of the headings from a Web page and reading them out as a list . A very simple and elegant solution which gives the user a quick way to find out what is on a particular page.

But will this work on pages ‘marked up’ in a similar fashion to my example above? i.e. on pages that have used CSS style rules as a substitute for proper markup? Clearly the answer is no. Without clear rules about what constitutes a heading, automatic processing of Web pages is not possible (or is very difficult) – and blind or visually impaired users are going to find the Web a harder place to get around. The same rules apply to any program that needs to process an HTML document which leads us to our next example, search engines.

Reason 2: A Search Engine indexing a Website

I believe that accessibility on the Web is not just about making sure a Website is accessible to disabled people; it is about ensuring pages are accessible to all Internet enabled devices or applications capable of processing them. An example of an application built to process Web pages is a Web based search engine.

Traditional search engines (i.e. not directories) collect text from Web pages by using software robots or ‘spiders’ that roam the Web by following links on Web pages. A spider visits a web page, reads it, and passes on the text it finds to a searchable database. How does a search engine decide what bits of text are important and what bits are not? Consider the following,

“Some of the search engines seem to pay more attention to the page headings than regular text, so you’ll want to take advantage of this.” Promotion World

Heading
“Many search engines give extra weight and importance to the text found inside HTML heading sections. It is generally considered good advice to use headings when designing web pages and to place keywords inside headings. ” Search Engine Terms

Use the heading tags: (<h1>, <h2> to provide structure to your text. Search indexers (Altavista, Google, etc.) go through your documents and use the headings to determine content. Descriptive headings can improve your showing in the search engine indexing. When a search engine finds keywords inserted in headings and high up in the page, you get bonus points.Search Engine Optimization/globalSecurity.org

As we can see from the above advice, one of the factors a search engine uses to rank search results is the words that appear in the headings of a Web page. It is assumed by many search engine robots that headings are likely to include important clues about the subject of a particular Website. This makes sense – if you want to rank high on the search engines you should ensure that the headings on your page contain the words that you expect potential visitors to search for. If you have no headings clearly there is the risk that your search ranking will suffer. And that means your competitors pages will be found before yours. Is your search engine ranking important? Are properly marked up headings important?

Something else that might be important to you is the accessibility of your pages to people using different types of browser and hardware, which takes us neatly to my next reason…

Reason 3. Use of personal stylesheets and stylesheets for different media types

Cascading Style Sheets are a good idea because they allow document structure to be divorced from document presentation. As Michael G. Paciello in his book Web Accessibility for People with Disabilities explains:

“By separating presentation from structure, specialized technologies used by people with disabilities can easily interpret the structure and render it properly to users.”

Thus with a properly marked up document and a suitable set of style sheets you can have a document that prints properly, works well for someone using a refreshable Braille display and looks good on WebTV. Different style sheets for different output devices adds a whole new dimension to the term reusable content.

Properly marked up documents also allow individuals to apply their own personal style sheets to Web pages. I may not want large yellow text on a black background, but there are people who do, because it makes the page easier for them to read.

Applying a style sheet to a document that has no structured markup is like trying to fire an expensively sculpted and exquisitely sharpened arrow with a bow made of spaghetti. Either way you are not going to get very far.

Use of personal stylesheets, support for media types (e.g. a separate style sheet for different output devices) and aural presentation – are all well and good – but they will be rendered useless with no structured markup to operate with.

How did this come about? – and what can we do about it?

It is clear that this is not a problem with style sheets (which I think are a great idea) but a problem with the way designers and Web design packages are implementing them. I can only speculate about how we have arrived at this situation. It could be that WYSWYG Web design packages now act so much like standard wordprocessors that they are used in just the same way, i.e. highlight some text, click a button to make it bold, click another button to make it bigger and use a dialog box to add some colour.

How does the software being used to help design a page know that the styled text is a header and not just some highlighted text in the middle of a paragraph. It doesn’ t of course – so somewhere along the line – there needs to be some intelligence added to the process.

As things stand, with the existing WYSWYG design packages, the intelligence has to come from the designer. A conscious decision is required to ensure that heading are marked up as headings, paragraphs are marked up as paragraphs and lists are marked up as lists. This requires a commitment to the notion that markup and presentation are two different things and that marking up the structure of a document is as important as worrying about how it looks. Or should that be more important than how it looks?

The introduction of Cascading Style Sheets was a great idea, but the invention of Hypertext Markup Language was an even better one – and the former depends on proper application of the latter.

Give me a phone if you would like me to test the accessibility of your website:

I provided feedback on the WCAG 2 (as representative of Guild of Accessible Website Designers) have two decades of experience and worked with hundreds of organisations.

07810 098 119

Alternative access to client feedback

Client Quotes

Loading Quotes...