Introduction to web standards

[Narrator:] In this chapter you will learn how to create accessible web publications. All web-related data formats, protocols and guidelines are standardised by the World Wide Web Consortium, which is often abbreviated to W3C or the Consortium. The Consortium is an international community where member organisations, a full-time staff and the public work together to develop web standards.

The two core technologies defined by the Consortium for building web pages are the Hypertext Markup Language, HTML for short, and the Cascading Style Sheets, CSS for short. HTML provides the structure of a web page and CSS the layout. Along with graphics and scripting, HTML and CSS form the basis of building web pages and web applications.

One of the Consortium's primary goals is to make the benefits of the web available to all people, independently of their hardware, software, network infrastructure, native language, culture, geographical location, or physical or mental ability.

The Consortium founded a working group dedicated to this goal, the Web Accessibility Initiative, WAI for short. The Web Accessibility Initiative publishes a set of standards to support people in creating accessible web pages.

Web Accessibility Initiative standards

At the time of creating this course, the Web Accessibility Initiative has published the following standards relating to the creation of accessible web pages.

• The Web Content Accessibility Guidelines, WCAG for short, were published in version 2.1.
• The Accessible Rich Internet Applications, WAI-ARIA or ARIA for short, were published in version 1.1.

In the chapters that follow we will discuss many aspects of these standards.

The following standards are less important for our course:

• The Authoring Tool Accessibility Guidelines, ATAG for short, are useful for creating accessible authoring tools, such as software and services, that authors (for example, web developers, designers or writers) use to produce web content. This content could be HTML editors, content management systems and websites that allow users to add content, such as blogs and social networking sites.
• The User Agent Accessibility Guidelines, UAAG for short, are useful for creating accessible user agents, such as browsers, browser extensions, media players, readers, and other applications that render web content.

This course does not discuss the creation of authoring tools and user agents, but will focus on the WCAG and ARIA standards.

How the components relate

It is important to ensure that all the components of the web development process and of the user interaction process work together.

A developer or author creates web content using an authoring tool. In its most basic form, this can be a text editor for writing HTML and CSS code. Or they may use a complex Content Management System for managing the information resources of websites with thousands of web pages. If the content to be created is media related, then audio or video editors may be used. It is important that the applied tools allow the author to create content following the Web Content Accessibility Guidelines.

Once the web content has been created, evaluation tools can help the author to test the resulting content for accessibility. Is the HTML code correct and does it contain any syntax errors? Do all the images have an alternative description? Evaluation tools can help the author to improve the accessibility of the code using automated processes to check large volumes of web content in a short time.

Once the content has been published, a user can access it using a web browser, media player or similar software or device. The reader used should itself be accessible, otherwise the user would not be able to interact with the content.

Sometimes the reading software must be supported by assistive technologies. These are hardware and/or software solutions that adapt the information interface so that the content can be consumed by the user. One example is a screen reader, which converts visual text information into an audible form, so it can be consumed by people with visual disabilities. The assistive technology and the reading software have to work closely together to guarantee the best possible user experience.

As you can see, each of the standards published by the Consortium describes precisely defined tasks, each with its own responsibility, establishing a smooth content creation, transmission, reading and interaction workflow.

Web Content Accessibility Guidelines

In the following chapters we will have a closer look at the Web Content Accessibility Guidelines, which describe how to create accessible web content. Before we go into the details of how to create accessible content, we should understand how it is structured and what problems are covered.

The Web Content Accessibility Guidelines offer 13 guidelines, following 4 principles. The 4 principles are: perceivable, operable, understandable and robust.

First principle: perceivable. Information and user-interface elements must be presented to users in a way they can perceive. The guidelines for this principle are to:

• Provide text alternatives for non-text content, such as alternative descriptions for images.
• Provide captions and other alternatives for multimedia, such as text transcripts, captions, sign language or audio descriptions.
• Create content that can be presented in different ways, including by assistive technologies, without losing meaning.
• Make it easier for users to see and hear content, for example by the selection of colours, choosing a sufficient contrast or having resizable text.

Second principle: operable. User-interface elements and navigation must be operable. The guidelines for this principle are to:

• Make all functionality operable via a keyboard.
• Give users enough time to read and use content. This is especially necessary when using user interfaces that change over time or use time-outs.
• Do not use content that causes seizures or physical reactions. This guideline should be respected by those using animated or flashing content.
• Help users to navigate and find content. Often navigation elements are designed in a confusing way or do not behave in a way a user would expect.
• Make it easier to use input devices other than a keyboard. This is especially important for those users with limited control of their hands.

Third principle: understandable. The information and the operation of the user interface must be understandable. The guidelines for this principle are to:

• Make text readable and understandable. Language should be used correctly and unusual wording and abbreviations avoided.
• Make content appear and operate in predictable ways. The navigation and user interface element identification should be consistent.
• Help users to avoid and correct mistakes by offering human readable and understandable error messages, correct form labelling and error prevention mechanisms.

Fourth principle: robust. Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies. The guideline for this principle is to maximise compatibility with current and future user agents. In general, this guideline is asking for error-free coding, so that the code can be parsed. Beyond that, the HTML elements should be applied correctly. We will see many examples of this in the following chapters.

WCAG success criteria

For each guideline, the WCAG standard provides testable success criteria to be used where requirements and conformance testing are necessary. In order to meet the needs of different target groups and different situations, three levels of conformance are defined: A, AA and AAA, where A refers to the lowest requirements and AAA to the highest.

Let's discuss this in an example: the use of colour. To fulfil the success criterion of level A, colour should not be used as the only visual means of conveying information, indicating an action, prompting a response or distinguishing a visual element. To achieve level AA, the visual presentation of text and images of text need to have a contrast ratio of at least 4.5 to 1. To reach the highest goal, the level AAA, the visual presentation of text and images of text has to have a contrast ratio of at least 7 to 1. Please refer to the chapter 'Fonts, sizes and colours' for a detailed explanation of these terms.

A website is considered to be compliant with a success criterion when all its web content fulfils the success criteria of the same level and all the levels below. For example, if your goal is to create a website with AA compliance, then all the web pages and web content have to fulfil the success criteria of AA and A.

History

To understand why there are different versions of the Web Content Accessibility Guidelines, we have to look at their history.

WCAG 1.0: Version 1 of the Web Content Accessibility Guidelines was published in 1999. The different guidelines were limited to the description of correct web page coding. Technologies like PDF, JavaScript or plug-in extensions such as Java Applets, Shockwave or Flash were explicitly excluded. There was no documentation explaining how to interpret the guidelines. There was no example code. This left a lot of room for different interpretations and implementations. There was no possibility for adapting to new developments, meaning it was quickly technically outdated.

WCAG 2.0: The Web Accessibility Initiative learned from this and worked on version 2 of its guidelines, which were published in 2008. The Web Content Accessibility Guidelines version 2 were established as a real ISO standard. So WCAG 2.0 and ISO standard 40500:2012 are one and the same document issued by different publishers. Version 2 was written in such a way that the guidelines can be applied to a multitude of different file formats.

Beyond HTML for web pages, WCAG 2.0 can be applied to documents stored in many other file formats such as PDF, EPUB, Microsoft Word and Scalable Vector Graphics. The nature of a standard is that it does not change.

To adapt to new technologies, the standard uses generic guidelines. The supporting documents offer additional information on how to understand and implement the guidelines. These documents can be updated to suit new requirements without releasing a new version of the standard.

The supporting documents are:

• How to meet WCAG: a customisable quick reference to Web Content Accessibility Guidelines that includes all of the guidelines, success criteria and techniques for authors to use as they are developing and evaluating web content.
• Understanding WCAG: a detailed reference for understanding and implementing the Web Content Accessibility Guidelines.
• Techniques for WCAG: targeting developers, this document offers a collection of techniques and common failures, each in a separate document that includes a description, examples, code and tests.

WCAG 2.1: Technological development required an updated version 2.1 of the Web Content Accessibility Guidelines, which was published in 2018. Version 2.1 includes all of the guidelines in version 2.0 and establishes 17 additional success criteria to be met.

The key changes in this version are to:

• Improve mobile accessibility; for example, do not change the content when rotating a mobile device. Many devices are permanently mounted on wheelchairs, which makes it impossible for the user to rotate the device. For the same reason, shaking should not be a required input for an application.
• Improve document-reading experience for people with visual impairments. A document should be readable without the need for horizontal scrolling. A responsive design should make sure that documents can be read using vertical scrolling only.
• Support autocomplete functions for people with cognitive and learning disabilities.

Accessible Rich Internet Applications: Today's web pages are more and more interactive. Web documents use dynamic elements, which change their appearance upon user interaction. Web developers increasingly use client-side scripts to create user-interface controls that cannot be created with HTML alone. They also use client-side scripts to update sections of a page without requesting a completely new page from a web server. Web user interfaces mimic those of desktop systems more and more. They use, for example, drop-down menus, tabs, modal dialogue boxes, alert boxes, autocompletes and slideshows.

These user interface controls and content updates are often not accessible to users with disabilities, especially screen reader users and users who cannot use a mouse or other pointing device. This is where the Accessible Rich Internet Applications standard, WAI-ARIA or ARIA for short, comes in. ARIA allows web pages to declare themselves as applications rather than as static documents, by adding role, property and state information.

Similar to the WCAG standard, the ARIA standard offers supporting documents. The WAI-ARIA Authoring Practices provides detailed advice and examples directed primarily to web application developers. An additional set of documents is dedicated to user agent implementation, for example the Core Accessibility API Mappings. These highly technical documents are of minor interest to document authors.

Demo

We have talked a lot about standards and what they offer us. But what does this mean practically? How does a non-accessible web page differ from an accessible web page? This can be best explained with a little demonstration. We have loaded two different versions of a fictional web page. Can you tell which version is accessible and which one is not accessible? Mmmh… Difficult, isn't it?

This is one very important message we learn here. Accessibility is not always visible! This makes it very difficult for people to understand the concepts of accessibility. Here is a web page offering some kind of header with a banner image. Below we see a search input field and two navigation areas, one on the left side and the other one above the content. The navigation on the left side seems to offer links to chapters and sub-chapters, indicated by different background colours. The content area offers text and images. The text is structured into different parts, which, as we can see, are separated by different headings. The headings have different font sizes, which leads us to the assumption that the content is nested. The text content itself is presented with paragraphs, a table and a list. At the end of the page we see a little form button, which can be used for some kind of interaction. A footer reminds us that there are copyrights on this page. All this can be recognised by a sighted user immediately.

A person with visual disabilities does not have any of this information. They have to use a screen reader, which reads the text to the user. When we say 'text', we mean text and only text. A screen reader cannot interpret the content of images. Let's start the screen reader.

[Screen reader:] VoiceOver on Safari, Accessibility demo, window. Accessibility demo, web content is keyboard focus.

[Narrator:] The screen reader welcomes us and tells us where we are, so that we have an idea where to start. We enter the web page, [Screen reader:] Link, image, header_2400 400 png.

[Narrator:] Mmmh… When reaching an image, the screen reader reads the file name of the image. This can be very confusing. Wouldn't it be better to have an alternative text that could be spoken when the screen reader cursor reaches the image?

[Screen reader:] Edit text.

[Narrator:] Here is the search input field, but we are not informed about what this input field is.

[Screen reader:] Link A. Link A. Link A.

[Narrator:] As a sighted user, I know about the three As indicating a possibility to increase or decrease text size, but the screen reader does not offer this information.

[Screen reader:] List, 3 items. Link, Contact, 1 of 3. Link, Home, 2 of 3. Link, Sitemap, 3 of 3.

[Narrator:] The next strange phenomenon is the reading sequence. The screen reader does not use the visual presentation as its reading sequence. Next problem… [Screen reader:] End of list. Link, Lewis Carroll. Link, About Alice. Link, Introduction.

[Narrator:] We can hear the text of the navigation links, but the screen reader does not tell us that this is a navigation area, nor about the nested structure of chapters and sub-chapters. Let's continue…

[Screen reader:] Link, Alice's Adventures in Wonderland. Link, Through the looking glass. Link, Resources. Link, History. Introduction.

[Narrator:] Finally we reach the content.

[Screen reader:] Image 1, png image. Alice's Adventures in Wonderland, commonly shortened to Alice in Wonderland, is an 1865 novel written by English author Lewis Carroll, the pseudonym for Charles Dodgson. It tells of a young girl named Alice, who falls through a rabbit hole.

[Narrator:] We can read it, but we do not get any information related to the formatting, such as the nesting level of the headings.

[Screen reader:] … especially in the fantasy genre. Image 2, png image.

[Narrator:] Let's continue with the table.

[Screen reader:] Main characters. Table, 2 columns, 3 rows. Name, column 1. Description, column 2. Row 2, Alice, column 1. Alice is a child in the mid-Victorian era, column 2. Row 3, The White Rabbit, column 1. The White Rabbit appears at the very beginning of the book wearing a waist-coat, and muttering 'Oh, dear! Oh, dear! I shall be too late', column 2.

[Narrator:] Even though we are informed that this is a table, we do not know much about its content or its structure. What information is part of the header? What is content related data? What data belongs to which header? This is a very frustrating user experience.

[Screen reader:] End of table. Language test. List, 3 items.

[Narrator:] We continue with text written in a different language from the main language of the document.

[Screen reader:] Bullet. This is a paragraph in English, 1 of 3. Bullet.

[Screen reader reading the text in German], 2 of 3. Bullet.

[Screen reader reading the text in French], 3 of 3.

[Narrator:] This sounds really bizarre. German and French texts spoken with English pronunciation.

[Screen reader:] End of list. Help us. Please give us your opinion.

[Narrator:] And now the button. We would like to communicate our opinion, so we press the button.

[Screen reader:] Please give us your opinion.

[Narrator:] We can see that a modal dialogue box was opened, but the screen reader does not tell us anything about it. The screen reader cursor is still at the old position and has not been moved to the modal dialogue box. Screen readers often offer us the possibility to get an overview of the page. The VoiceOver screen reader does this via the web rotor. Please note that other screen readers may offer different mechanisms with similar results.

[Screen reader:] Links menu.

[Narrator:] The screen reader presents us a list of the links in this web page. It uses the content inside the hyperlinks. If this content is not self-explanatory, then the user will have no idea what to expect behind the links. This is especially true for links with repeating texts like “more information” or “click here”.

[Screen reader:] Tables menu.

[Narrator:] Next we get an overview of all the tables in the page. If there were multiple tables, we would have no way of navigating to a specific table as we do not have a description of the table content.

[Screen reader:] Form controls menu.

[Narrator:] Let's look at the forms. The rotor shows us a form, but we have no idea what it is about.

[Screen reader:] Images menu. Here we see a list of the images that are part of this web page. The only image related information the screen reader can offer is the image’s file name. If the file name has been chosen in a meaningless way, then a user with visual disabilities will get no information about the image.

[Screen reader:] Please give us your opinion.

[Narrator:] All in all, a user with visual disabilities will not have much fun with this web page. We lost a lot of time with confusing and inaccessible navigation. The structure of the content is not obvious and is therefore difficult to understand. Let's try the other web page.

[Screen reader:] Accessibility demo, web content.

[Narrator:] From a purely visual point of view, this page looks nearly identical.

[Screen reader:] In Accessibility demo, web content, header of the website, banner.

[Narrator:] However, now the screen reader offers us much more information. It tells us that the web page starts with a banner block. A web page can be structured in information blocks, which can be assigned to landmark roles. With landmark roles we can define blocks of web content as being responsible for presenting navigation elements, complimentary sidebars, the main content or, as we have heard here, a banner.

[Screen reader:] Link, image. Collage of original illustrations from Alice's Adventures in Wonderland, drawn by John Tanniel.

[Narrator:] The screen reader was able to describe the content of the image using an alternative description. If an image has a function, such as being part of a link, then a description of the function could be added as well. In our example the user hears a description of the image and a hint that it offers a link to the home page. Let's read more.

[Screen reader:] End of header of the website, banner. Search. Enter a key word for full text search and press return. Edit text.

[Narrator:] We have left the banner block and reached the full text search. The area is marked correctly as a search input. When entering the input field, the screen reader informs us about possible actions we can make here.

[Screen reader:] End of search. Function navigation menu. Navigation. Link, a smaller size text. Link, a medium size text. Link, a large size text.

[Narrator:] Note how the screen reader found additional information to explain the role of the three A characters. As you can hear, we can add information to a web page, which is for screen readers only, invisible to sighted users. We have entered a navigation block.

[Screen reader:] List, 3 items. Link, Home, 1 of 3. Link, Sitemap, 2 of 3. Link, Contact, 3 of 3. End of list.

[Narrator:] The screen reader now reads the navigation elements in the correct order. Next, we learn that we can have more than one landmark role of the same type. In our example we have two navigation blocks. As we labelled them correctly with their own name, a user with visual disabilities can distinguish them.

[Screen reader:] End of navigation menu, navigation. Main content navigation menu, navigation. List, 4 items. Link, Lewis Carroll, 1 of 4. Link, About Alice, 2 of 4.

[Narrator:] Note how the screen reader informed us about the structure of the navigation. The screen reader detected a list of four elements. These are the elements of the top level navigation. Let's hear how the screen reader presents nested sub-levels.

[Screen reader:] List, 3 items, level 2. Link, Introduction, 1 of 3. Link, Alice's Adventures in Wonderland, 2 of 3. Link, Through the looking glass, 3 of 3. End of list. Link, Resources, 3 of 4. Link, History, 4 of 4. End of list. End of main content navigation menu, navigation.

[Narrator:] The screen reader detects a list within the list and describes the hierarchy of the navigation exactly. We are informed when we reach a nested level and when we leave it. We have reached the end of the navigation block and enter our main content.

[Screen reader:] The content of the page, main. Heading level 1, Introduction.

[Narrator:] As you can hear, headings are introduced with their correct nesting level.

[Screen reader:] Alice in the shower of cards, image. Alice's Adventures in Wonderland, commonly shortened to Alice's in Wonderland, is an 1865 novel written by English author Lewis Carroll. … culture and literature, especially in fantasy genre. The White Rabbit blowing his trumpet, image.

[Narrator:] We continue with our table.

[Screen reader:] Heading level 2, Main characters. A table with some characters of the novel. Table, 2 columns, 3 rows. Name, column 1. Description, column 2. Row 2, Name, Alice. Column 1, Description. Alice is a child in the mid-Victorian era. Column 2, row 3, Name, The White Rabbit. Column 1, Description. The White Rabbit appears at the very beginning of the book wearing a waist coat and muttering 'Oh, dear! Oh, dear! I shall be too late'. Column 2.

[Narrator:] We are informed that we enter the table and how the table is structured. We can distinguish header information from content data. Even if we are in the middle of a table, the screen reader offers us table data in combination with the related table header. This way we get a much better overview of the data. We continue with the multilingual text.

[Screen reader:] End of table. Heading level 2, Language test, list, 3 items. Bullet, This is a paragraph in English, 1 of 3.

[Screen reader reading the text in German], 2 of 3.

[Screen reader reading the text in French], 3 of 3. End of list.

[Narrator:] If marked correctly, a screen reader can read texts using different languages. Of course, the screen reader requires a matching voice for reading text with the correct pronunciation.

[Screen reader:] Heading level 2, Help us. Please give us your opinion, button Access key available B. Press, Do you really want this?, web dialogue.

[Narrator:] When we click the form button, the modal dialogue box opens and our screen reader cursor is moved into the dialogue box without additional user interaction. Using the Tab key, we can now explore all the options of the dialogue box.

[Screen reader:] Do you really want this?, web dialog. Close, button. No, button. Yes, button.

[Narrator:] Note how the X is described as a close button.

[Screen reader:] No, button. Close, button.

[Narrator:] For now we decide that we do not want to communicate our opinion and just close the dialogue box.

[Screen reader:] Press Close, button.

[Narrator:] Once we press a button, we are at the position where we left off.

[Screen reader:] End of the content of the page, main. The footer of the page, Content information.

[Narrator:] Let's see how the screen reader presents the page overview for this web page. To get the page overview, we start the web rotor of VoiceOver.

[Screen reader:] Links menu, link image, Collage of the original illustrations from Alice's Adventures in Wonderland, drawn by John Tannel.

[Narrator:] The links now have meaningful texts, which significantly eases navigation.

[Screen reader:] Tables menu. A table with some characters of the novel, 2 columns, 3 rows.

[Narrator:] We can access all the tables directly. The overview shows us all the available tables using their descriptions. If multiple tables exist, we would be able to distinguish them by their description.

[Screen reader:] Form controls menu.

[Narrator:] Next, we see all the forms on this page. In our example we see two forms: the full text search and the button.

[Screen reader:] Landmarks menu.

[Narrator:] Next, we see all the landmarks.

[Screen reader:] Header of the website banner. Search. Function navigation, menu navigation. Main content, navigation menu navigation. The content of the page, main. Headings menu [Narrator:] We can see all the headings of the page including their levels.

[Screen reader:] Heading level 1, Introduction. Heading level 2, Main characters.

[Narrator:] When we were using the non-accessible version, this information could not be offered. We can select any of these headings and will be forwarded directly to this part of the page. There is no need to start reading the page from the beginning.

[Screen reader:] Images menu.

[Narrator:] The images appear using their alternative descriptions, which makes it much easier to identify them.

[Screen reader:] Collage of the original illustrations from Alice's Adventures in Wonderland, drawn by John Tennol, image.

[Narrator:] Note how the banner image appears in the image section as well as in the link section as it is both an image and a link. When comparing the navigation possibilities of both pages, it is obvious how important accessibility is for users with visual disabilities. In the worst case scenario, a user with visual disabilities cannot use a web page at all, especially those with highly interactive content.

Visual appearance of a web page

Let's summarise what we have learned so far. When looking at a web page, a sighted user immediately recognises different function blocks: banner, navigation, content, side box, footer and so on. They can also detect different headings, paragraphs, lists and tables. Input elements signal one or more interactive forms. A user with visual disabilities does not have this information when facing a non-accessible web page.

Navigation without structure: A totally non-accessible web page has no structure. Therefore, all content has to be read in sequence. There are no possibilities to jump to the content part or a specific heading. The only possibility to change the screen reader cursor position is the full-text search of the browser, but then the user would need to know what to search for. All in all, this kind of web page results in a very frustrating user experience.

Navigation with structure: An accessible web page offers many different navigation features that enable the user to consume the content in multiple ways. A user with visual disabilities can get a quick overview of the structure of the web page before starting to read its content, just like a sighted user can. The user may decide to pass the banner and navigation blocks to get directly to the content. Different lists showing landmarks, headings, forms, tables, links or images ease navigation significantly. Multiple navigation options offer choices and enable the user to browse content according to personal preference.

Principles of web navigation These are the options a user with visual disabilities has to navigate a web page when using a screen reader. The number of navigation options increase with the level of accessibility.

• HTML Coding.
• HTML Testing.

Where to continue?

You have been introduced to web standards related to accessibility. With a practical demonstration, we have shown why they are so important.

Depending on your personal interests, you could continue with one of the following chapters.

• HTML Coding.
• HTML Testing.

[Automated voice:] Accessibility. For more information visit: op.europa.eu/en/web/accessibility.

Close tab