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

WCAG 2.1 Guidelines Explained

Published: April 12, 2022

A history lesson: where did the website accessibility guidelines come from and what’s in them?

  • 1995: The first web accessibility guidelines were compiled by Gregg Vanderheiden shortly after the 1995 Chicago WWW II Conference.
  • 1998: University of Wisconsin–Madison compiled the Unified Web Site Accessibility Guidelines.
  • 1999: they formed the basis for WCAG 1.0.

WCAG 1.0. were focused on HTML and web pages.

  • 14 guidelines.
  • 65 checkpoints.
  • Each with a priority level: A, AA. AAA.

A Compliance: the guidelines must be satisfied otherwise it will be impossible for one or more groups to access the Web content.

AA Compliance: should be satisfied, otherwise some groups will find it difficult to access the Web content.

AAA Compliance: may be satisfied: to make it easier for some groups to access the Web content.

14 WCAG 1 Guidelines

  • Guideline 1: Provide equivalent alternatives to auditory and visual content.
  • Guideline 2: Don’t rely on colour alone.
  • Guideline 3: Use markup and style sheets, and do so properly.
  • Guideline 4: Clarify natural language usage.
  • Guideline 5: Create tables that transform gracefully.
  • Guideline 6: Ensure that pages featuring new technologies transform gracefully.
  • Guideline 7: Ensure user control of time-sensitive content changes.
  • Guideline 8: Ensure direct accessibility of embedded user interfaces.
  • Guideline 9: Design for device independence.
  • Guideline 10: Use interim solutions.
  • Guideline 11: Use W3C technologies and guidelines.
  • Guideline 12: Provide context and orientation information.
  • Guideline 13: Provide clear navigation mechanisms.
  • Guideline 14: Ensure that documents are clear and simple.

WCAG 2 – Published 2008

Not just websites, but also PDF, Google Docs, Spreadsheets, e-Books… and other ‘digital assets’.

WCAG 2.1 – Published 2018

  • WCAG 2.1 does not deprecate or supersede WCAG 2.0.
  • The differences between WCAG 2.0 and 2.1 are mostly related to the use of tablets and mobile devices.
  • They are designed to make content more accessible to a wider range of people, including accommodations for blindness and low vision.

WCAG 2.1 Based on 4 Principles

  • Perceivable.
  • Operable.
  • Understandable.
  • Robust

What principles?

  • Perceivable?
  • Operable?
  • Understandable?
  • Robust?

What do the principles mean?

Perceivable

WCAG speak: information and user interface components must be presentable to users in ways they can perceive.

Jim speak: the site visitor must be able to recognise that the content exists. For example, by being able to see it, hear it or touch it.

Operable

  • WCAG speak: user interface components and navigation must be operable.
  • Jim speak: the site visitor must be able to navigate around the site and use the features and functions presented.

Understandable

  • WCAG speak: information and the operation of user interfaces must be understandable.
  • Jim speak: not only should visitors be able to recognise the existence of the content and be able to interact with it, but they must also be able to understand it.

Robust

  • WCAG speak: content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
  • Jim speak: it must be possible to access the content using everything from a text-only web browser to the latest Firefox browser. And everything in between, including screen readers and all the different brands and versions of browsers now available.

Each Principle Has A Set Of Guidelines

1. Perceivable: the guidelines relate to:

  • Text alternatives for non-text content.
  • Captions and other alternatives for multimedia.
  • Content can be presented in different ways, including by assistive technologies, without losing meaning.

Operable: the guideline Relate To:

  • Ensuring functionality is available for keyboard users.
  • Giving users enough time to read and use content.
  • Avoiding content that causes seizures or physical reactions.
  • Help users navigate and find content.
  • Making it easier to use inputs other than by keyboard.

Understandable: the guideline Relate To:

  • Make text readable and understandable.
  • Make content appear and operate in predictable ways.
  • Help users avoid and correct mistakes.

Robust: the guideline Relate To:

  • Maximising compatibility with current and future user tools.
  • For example, by using valid code.

For Each Principle

There are guidelines – these are the basic goals that authors should work toward in order to make content more accessible.

And For Each Guideline

Ther are ‘testable success criteria’.

  • Three levels of conformance are defined as: A (lowest), AA, and AAA (highest).
  • Techniques and examples are provided for meeting those criteria.

Mobile Platforms

  • All ‘success criteria’ apply to mobile platforms as well as desktop platforms.
  • However, the techniques sections does not yet fully cover mobile techniques.

Jim Byrne

So how do you add character encoding information?

Published: November 3, 2014

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.

How to get your XHTML pages to validate when using the blockquote element

Published:

This is a tip for those marking up their web pages by hand using XHTML strict. If you are the sort of person using XHTML it is likely that you will want to ensure your pages validate when tested with the World Wide Web Consortiums markup validator.

Would it surprise you if I said the following code doesn’t validate,


<blockquote cite="http//mywebsite.com">
Blah, blah, blah and so on..
</blockquote>

It looks simple enough – what could be wrong with that? I came across this very problem – and spent a half hour trying to figure out why it didn’t validate. I investigated various options – including thinking that I must have some strange, invisible and illegal characters in my quoted text somewhere. After scratching my head for a while I looked at the specifications for XHTML and found the answer.

To validate as strict XHTML, you must add a block-level element around the text within the <blockquote> tag, like this:


<blockquote cite="http//mywebsite.com">
<p>Blah, blah, blah and so on..</p>
</blockquote>

Problem solved – now the markup validates – and so will yours the next time you use blockquote in your XHTML documents.

Test the accessibility of your web page with your own web browser

Published:

It seems to be a little known fact – but it is worth remembering – that almost all Web browsers allow you to change the text size, font, colour and background colour of the web pages you visit.

Try experimenting with the setting in your own browser; check how your pages look with much larger or smaller text, or a different text/background combination. And even more importantly, check if the page design allows these attributes to be altered at all.

If they can’t be altered (perhaps because you have spent time trying to force the page to look the same on everybody’s screen), then this should alert you to the fact that your pages may not be as accessible as you thought.

An important aspect of accessible web design is giving users the ability to change the presentation of the page to suit their own needs – if they can’t do that then this should alert you to accessibility issues with your site.

Website and document accessibility auditing

If you require a more comprehensive and authoritative audit of your website or your documents (for example, checking the accessibility of your PDF’s) then please get in touch as that is exactly what we do. We’ve been very very good at it since 2005.

Contact us today to discuss your project

Or phone to talk over your ideas: 0141 576 9446.

Web Site Accessibility and Web Standards – Get More Visitors and Make More Money

Published: August 8, 2014

Most website commissioners are not interested in Web Standards or Web accessibility – that is clear from the results of DRC Research carried out in the UK in 2004. The research highlighted the appalling lack of accessibility of most UK web sites – with 81% labelled by researchers as ‘impossible’ to use by many disabled people.

So if you are a web developers, don’t waste your time trying to get clients excited by your ethical approach. Instead just get on with the job of creating accessible standards based websites — and tell them you use development methods that will help them attract more visitors — and help them make more money.

Use Web Standards — money can be saved and money can be made

Pages built using web standards tend to be smaller and they tend to load quicker. This leads to the first and most obvious saving – lower bandwidth costs.

What is not so obvious, however, is that faster loading pages can also generate additional traffic and revenue. For example, when Multimap.com redesigned their site using web standards they estimated they saved 40,000 Gb of bandwidth per year – but they also found that their advertising revenues increased. The quicker loading pages encouraged people to spend more time on the site – and consequently advertising revenues went up.

Accessible websites make more money

Julie Howell, Digital Policy Development Officer at the RNIB, talking about one of Tesco’s websites — a website designed to provide easier access for blind and visually impaired people,

“Many fully-sighted people find Tescoís simply designed Access site offers them a better user experience than any other supermarket website. Developed for vision-impaired users, it now takes a surprising £13 million a year, and seems to attract a much wider audience than originally intended.”

Accessible websites attract more people

Apart from the 10 million Disabled people in the UK and 50 million in America, accessible websites will be easier to use by older people, people with slow connections or older technologies and people with low literacy. Older people are the fastest growing group of new users in many countries. As many older people have multiple impairments, accessible sites are likely to be more attractive to this group.

Disabled people and older people have money to spend

In the UK Disabled people have £50 billion of disposable income, in the USA they have US$175 billion. Older people currently control over 80% of the wealth of the UK. As was demonstrated by Tesco — making your website even a little more accessible not only brings you good press – it attracts the attention of the community of older people and disabled web surfers – who spend their money on your website rather than your competitors.

Web Standards means shorter development times and re-usable content

Production and maintenance costs are lower when content is package in highly structured ways, for example, when standard (X)HTML is used. Separating the structure of content, i.e., headings, lists, images, paragraphs, from the way that content is presented opens up opportunities to create multiple ‘views’ of that content.

As a result, content can be optimized with less effort for delivery on hand-held devices, formatted for printing or delivered to assistive devices such as screen readers.

When the time comes around for a new design, it is easier to substitute a new style sheet than to spend hours changing hundreds of font tags and background colour attributes.

Web standards means you don’t waste time battling with Browser quirks

When using Web standards there is no need to produce multiple versions of pages to cope with the quirks of different browsers. The time and effort previously required to create and maintain ‘browser sniffing’ scripts can now be re-deployed to add value to the site for visitors.

Web standards helps you break free from proprietary technologies

Using Web standards can free organisations from being captives of browsers dependent on proprietary tags and rendering behaviour. For example, IBM’s move to Open Source desktop clients has reportedly been held back due to their web based systems being built on top of the non-standard Internet Explorer web browser.

Less errors in pages means less time dealing with complaints

Without working to standards – it is not possible to check for markup errors; there are no rules to check against. Standards base web pages can be checked against code validators such as the W3C validator – highlighting any errors – and allowing you to get those errors fixed. If you website works for more people on more browsers you won’t have to spend time replying to emails from people complaining your site doesn’t work.

Content is future-proofed and compatible with older browsers.
Pages built using web standards will display more consistently across browsers and platforms, including older browsers. Your content will not necessarily look the same in old ‘non-standard compliant’ browser but the bottom line is that the content will still be available.

Greater search engine visibility

Search engines are able to index web pages more accurately if the content on those pages is well structured. For example, when keywords appear in page headings many search engines give extra weight to those words when indexing the page. A web page where headings are improperly marked up is likely to suffer in the search rankings compared with a page with the same content that is marked up correctly. An accessible website will have alternative text for images and multimedia – and this will provide more text be indexed by search engines.

Accessible websites designed using Web Standards leads to real measurable benefits: more visitors, increased income, decreased cost, greater search engine visibility, faster loading and easier to use pages. Sell the benefits to websites commissioners, not the ideology.

This article was written by Jim Byrne, a Web site accessibility specialist since 1996. He is the founder of the Worldwide Guild of Accessible Web Designers and author of the QnECMS – the accessible CMS.

Contact us now if you are interested in having your own accessible website built using Web Standards.

Let's Chat

07810 098 119

Alternative access to client feedback

“The audit was extremely comprehensive, clear and demonstrated Jim’s expertise in the area of accessible web design.” Peter Madden, Project Manager, Sealed Envelope Ltd