Running dynamic websites that use complex content management systems benefit from quick loading times. This is because they ensure good performance and therefore increase user-friendliness. With the release of PHP7, a new scripting language is now available with which the loading times of your own website can be significantly shortened compared to the older script version.
The World Wide Web isn’t easy for everyone to access in the same way. People with disabilities, in particular, are often dependent on a special presentation of the web offer in order to be able to experience and understand the content. For example, sensory restrictions require presentation forms such as a read-aloud function, subtitles, audio descriptions, or the output of content via a Braille display. Web offers that have been appropriately edited enable people who are dependent on specific presentations to participate in one of mankind’s greatest projects: the internet. This is what’s known as barrier freedom, or accessibility.
Whether or not a web application is considered accessible depends on the scale. The most important international standard for the assessment of web accessibility is the WCAG, which forms the basis for the Information and Communications Technology (ICT) policies in the UK, among other things. In the following article, we give you an overview of the guidelines and explain the standardised procedure for evaluating web offers according to WCAG.
What is WCAG?
In the Web Content Accessibility Guidelines (WCAG), the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C) defines recommendations for the accessibility of web offers. The guidelines law out how content should be formed on the internet so that all users can access it - despite their physical, mental, or technical capabilities. The WCAG is currently on Version 2.0, published in December 2008. WCAG 2.0 replaced the previous standard, WCAG 1.0.
The World Wide Web Consortium is an international standardisation board for web technologies like HTML, XHTML, XML, RDF, OWL, CSS, SVG, and WCAG. The founder and chairman of the members’ organisation is Tim Berners-Lee, a British computer scientist who is the inventor of the World Wide Web.
Differences between WCAG 1.0 and WCAG 2.0
The goal of W3C is to provide website operators with an international standard for accessibility in web projects through the WCAG, which seeks to meet the needs of individuals, as well as those of organisations, and government institutions.
Compared to the previous standard, WCAG 2.0 features a technology independent approach. The guidelines are formulated so that current technological standards, as well as future developments, can be dealt with.
One significant difference between WCAG 1.0 and WCAG 2.0 is the structure of the criteria list:
- Structure of WCAG 1.0: The Web Content Accessibility Guidelines Version 1.0 are separated into 14 principles, each containing 1 to 10 checkpoints of priorities 1, 2, and 3. Each checkpoint is assigned an example, which refers to the basic web standards HTML and XML.
- Structure of WCAG 2.0: The Web Content Accessibility Guidelines Version 2.0 provide a system subdivided into the 4 basic design principles of perceptibility, usability, intelligibility, and robustness. For each guideline, WCAG 2.0 provides a set of verifiable success criteria for the A, AA, and AAA compliance levels (see below). Website operators can’t necessarily find examples for the current standard but detailed descriptions and advice for technical execution have been placed on the information pages Understanding WCAG 2.0 and Techniques for WCAG 2.0 and linked to the respective success criterion.
Despite the differences in regard to the organisation of requirements and design criteria, WCAG 2.0 remains backward compatible. With it, a website can fulfill the requirements of both standards. The conversion of a website from WCAG 1.0 to WCAG 2.0 with the W3C only requires small adjustments. In the following sections, the criteria set of WCAG Version 2.0 is used.
Compliance levels of WCAG 2.0
A website is A-level compliant if all success criteria of level A are fulfilled or an alternate version of the website that does fulfill the criteria is available.
Low accessibility level
A website is AA-level compliant if all success criteria of levels A and AA are fulfilled or an alternate version of the website that does fulfill the criteria is available.
Intermediate accessibility level
A website is AAA-level compliant if all success criteria of levels A, AA, and AAA are fulfilled or an alternate version of the website that does fulfill the criteria is available.
High accessibility level
The “conformity” attribute always refers to a single web page (or a single HTML document available under its own URL) and can only be only be acquired for entire web pages. If a single section of a web page doesn’t fulfill the desired compliancy level requirements, then the web page as a whole isn’t awarded the level. If the web page is part of a click path across multiple pages that allows it to perform a specific action, then all web pages of the click path must exhibit the desired compliance level or higher. If just one web page doesn’t fulfill the requirements, then the desired compliance level is not given to the other web pages on the click path as well. An example:
An online shop would like to design its order process to meet the WCAG compliance level AA. The prerequisite for this is that all individual web pages involved in the context of the order process to create shopping carts, record customer data, or transmit payment information must also correspond to at least to compliance level AA.
As opposed to WCAG 1.0, WCAG 2.0 offers the possibility to implement individual aspects of the accessible web design on different compliance levels. For the color contrast aspect, for example, the current standard defines two success criteria and different compliance levels:
1.4.3 Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: (Level AA) […]
1.4.6 Contrast (Enhanced): The visual presentation of text and images of text has a contrast ratio of at least 7:1, except for the following: (Level AAA) […]
Website operators also have the option to issue a declaration of compliance for all web pages that meet the WCAG’s success criteria. These are created voluntarily and in no way affect the accessibility of the website. But if a website operator does decide to issue a declaration, the W3C has made the following information mandatory:
- Date of the compliance declaration
- Indication of which WCAG being referred to, including title, version, and link to the standard
- Indication of which compliancy level is fulfilled (Level A, AA, or AAA)
- Precise description of which web pages the domain in the declaration refers to (e.g. a list of all URLS)
- List of all essential web technologies used by the WCAG compliant ages and which affect their compliance
- In addition, website operators can also choose to expand the declaration of compliance with the following information:
- List of all fulfilled success criteria beyond the stated degree of compliance
- List of all web technologies used by the website that don’t affect the compliance of the website
- List of all user agents with which the website was tested
- Machine-readable version of the list of all essential web technologies used by the WCAG compliant web pages
- Machine-readable version of compliance declaration
- List of additional measures for accessible web design not related to WCAG
Absolute accessibility, which meets all of the requirements and restrictions of internet users with disabilities, can’t really be put into practice. A website can still be an obstacle even if it fulfills the requirements of the highest compliance standard (AAA) - especially in regard to cognitive restrictions, language or learning disabilities, and multi-handicaps. The W3C recommends that website operators implement as many success criteria as possible so that the largest possible group of people can participate on the internet.
Overview of the WCAG 2.0 guidelines
The Web Content Accessibility Guidelines subsist of 12 guidelines, subdivided into four basic principles. While the WCAG principles define the basis for accessible web usage, the guidelines give web developers, authors, and designers clear instructions that need to be taken into account for the creation of accessible content with a certain level of compliance. We provide a brief summary of these guidelines below.
According to the WCAG principles, accessible web pages feature content that is optimally perceivable, usable, understandable, and robust. The principles can be implemented as follows:
- Perceptibility: For optimal web usability, you should present content so that it’s perceivable by all internet users. The WCAG guideline on improving perceptibility for web content reads:
1.1 Text alternatives: A text-based alternate presentation makes it possible to transfer non-text content into other forms, such as capital letters, Braille, symbols, or simplified language.
The guideline for text alternatives only requires that for all non-text content such as videos, photos, or graphics on a website, there should be alternative descriptions based on text or subtitles. The following exceptions apply:
- If non-text content is a control element, time-based medium, test, or sensory element that serves a particular sensory experience, a descriptive alternate text should be available that at least enables the identification of the non-text content.
- For image- or sound-based CAPTCHAs, an alternate text must be available that describes the function of the non-text content. Alternate forms of the CAPTCHA with different output formats should be offered.
- Purely decorative elements aren’t provided with alternate texts and should be implemented in such a way that they’re ignored by assistive devices such as screen readers.
The success criteria are under compliance level A.
1.2 Multimedia content: The website provides alternate presentation forms for time-based media (i.e. audio and video content).
The guideline regarding alternative formats for time-based media includes rules for media alternatives for audio tracks and videos, as well as for synchronised media content in which the simultaneous perception of picture and sound along with other forms of presentation is indispensable for the experience of web page contents. Depending on the desired compliance level, descriptive texts, audio descriptions, subtitles, transcriptions, and sign language are available as media alternatives. This guideline covers 9 success criteria for compliance levels A, AA, and AAA.
1.3 Adaptability: The content of the website can be transferred into alternative display forms without any loss (simple layout).
The guideline for adaptability includes rules for alternative presentations for information given as a result of the structure of the website content, the reading sequence, or sensory properties such as shape, size, position, and orientation. The goal here is to make this information accessible to people with disabilities through the use of media alternatives such as descriptions in text form or software-based preparation for assistance systems. This guideline covers 3 success criteria for compliance level A.
1.4 Distinctiveness: Content is created in such a way that it’s visually and acoustically distinct from other content (color, font size, contrast, discreet background).
This guideline for distinctiveness includes rules for visual representation of website content. Specifications are related to the color scheme, contrast ratio of text and image elements to the background, text size, and scalability, as well as text block layouts. In addition, further requirements are defined for websites that work with audio content in the background. This guideline covers 9 success criteria for compliance levels A, AA, and AAA.
Usability: For accessible web content, the user interface should be designed in such a way that all internet users are able to access the desired information. The usability of web offers can be optimised using the following guidelines.
2.1 Accessibility via keyboard: For the best possible web usability, all contents and functionalities are accessible by keyboard.
The guideline for accessibility via keyboard defined the keyboard as the primary user interface. Other operation options such as control via mouse, trackball, or touchpad aren’t required. Keyboard traps to avoid are web pages that can be accessed via the keyboard but can’t be closed using only keystrokes (i.e., ESC). If keyboard traps (for example, in the form of an embedded Flash video) can only be navigated by means of special, uncommon key combinations, then users need to be informed of this possibility. This guideline covers 3 success criteria for compliance levels A and AAA.
2.2 No time pressure: Users are given sufficient time for interaction to read and use web content.
People with disabilities often need more time to interact with website content or carry out actions such as entering information. The guideline for time-based content makes sure that these users can also interact with the website without the content unexpectedly changing. Specifications in the framework of this guideline include mechanisms that allow for individual time management by disabling, modifying, or pausing automatic updates or time limits. This guideline covers 5 success criteria for compliance levels A and AAA.
2.3 Minimise seizure risks: All web content is designed to minimise any possible risk of seizures due to visual stimuli.
The guideline for seizure risks defines thresholds for visual stimuli that can lead to seizures. It specifies two success criteria for compliance levels A and AAA.
2.4 Navigation: The website provides users with means for easy navigation.
The guideline for navigation covers success criteria that should enable people with disabilities to identify their position with a website, find content, or skip to sections of content that are repeated on different websites of a domain. The specifications for accessible navigation refer to meta-titles, descriptions, link text, access to web pages, and headings and captions for text sections, as well as keyboard focus. The guidelines for navigation cover 10 success criteria for compliance levels A and AA.
- Intelligibility: Web content should be designed in such a way that the contained information, as well as the operation, is understandable. Web developers and authors can achieve optimal intelligibility using the following guidelines.
3.1 Readability: An optimal accessibility to web offers requires readable and understandable content.
The guideline for readability covers rules specifying how linguistic elements should be characterised and enriched with additional information in order to ensure optimal content accessibility. The success criteria define specifications for language versions, unusual words, abbreviations, and ambiguities, as well as reading level. All told, the WCAG gives 6 criteria for readability under compliance levels A, AA, and AAA.
3.2 Predictability: The behavior of functional and interactive web page elements always remains predictable.
To ensure good intelligibility, a website should be predictable. In this respect, the guideline for predictability defines specifications focused on web page elements, automatic content updates, and navigation. The proposed success criteria are under compliance levels A, AA, and AAA.
3.3 Accessibility tools: Easily accessible websites help visitors to avoid errors by automatically correcting them using accessibility tools.
The guideline for accessibility tools covers specifications for automatic error detection, help texts, and labeling of input fields, as well as input mechanisms for legally relevant data or financial transactions. Website operators have six success criteria available for compliancy levels A, AA, and AAA.
- Robustness: The WCAG principle of robustness refers to the compatibility of web content. To ensure easy accessibility, it should be designed in such a way that content can be processed reliably by the majority of agents used (web browsers, assisting output devices, etc.). Website operators can find corresponding specifications in the compatibility guidelines:
4.1 Compatibility: Compatibility with current and future technology is ensured with the consistent application of specific web standards.
An accessible website can be analysed in an optimal way. The basic prerequisite for this is that the implementation of content using markup languages like HTML is complete and error-free, according to the respective specifications. This includes gap-free recognition of all components of the user interface (such as links, forms, or components generated by scripts) so that their type and function can be read out on the software side. The guidelines for compatibility cover 2 success criteria for compliance level A.
The W3C Working Draft (the working version of WCAG 2.0), published on April 27, 2006, contained a checklist in the appendix that listed all of the success criteria defined by the W3C. It served as a sort of overview for many website operators. Since the publication of the official W3C Recommendation on December 11, 2008, this checklist is out of date.
The original checklist was replaced by an individually modifiable quick reference. This allows website operators to tailor the criteria catalog for accessible web design to their own needs (namely, their technical requirements and desired compliance level) with the help of a filter function to create custom checklists.
The specifications of the WCAG deal with testable success criteria, according to which website operators can assess the degree of compliance of individual web pages according to the WAI standard. For website operators that would like to check not only individual pages but also the accessibility of the entire web presence, the WAI has developed 4 strategies: Easy Checks, WCAG-EM, user-based evaluation, and evaluation tools.
The WAI cites basic aspects of accessible web design with Easy Checks. The list is intended to allow website operators to get a quick overview of the status of their online project. The following criteria are examined with Easy Checks:
- Alt texts
- Contrast ratio
- Text scalability
- Accessibility via keyboard
- Movable, flashing, or automatically starting content
- Multimedia alternatives
- Website structure
The validity in regard to the accessibility of the website is comparatively low. Further evaluations (for example, according to WCAG-EM) are necessary for a conclusive compliance assessment.
The Easy Checks serve to provide website operators with a first impression of the overall accessibility of their online project. For website operators who want to reliably and verifiably determine the WCAG compliance of their web project, the WAI developed a best practice approach with the Website Accessibility Conformance Evaluation Methodology (WCAG-EM). Compliance confirmation according to the WCAG-EM includes five steps:
- Determine the range of assessment: In the first step, website operators determine which areas of their online project should be included in the compliance evaluation and define the goal of the evaluation, as well as the desired compliance level (A, AA, or AAA).
- Analyse web presence: In the second step, website operators determine the central subpages and core functions of their online presence and classify the individual web page types in regard to functionality and content as well as layout and design. A list of all web technologies used on the analysed pages is also created.
- Select representative web pages: If the range of the web presence doesn’t allow for all pages of a project to be evaluated, then in the third step of the WCAG-EM website operators randomly select representative web pages for the compliance assessment.
- Evaluate chosen web pages: The fourth step of the WCAG-EM is the assessment of the samples. Website operators assess which success criteria of the WCAG meet the needs of the chosen web pages and which don’t. The results are recorded for the final report.
- Create compliance evaluation report: The last step of the compliance evaluation according to the WCAG-EM comprises of the creation of a report. This gathers together the results of the individual evaluation steps. Website operators can find support for creating the report in the WCAG-EM Report Tool.
Publishing the compliance report isn’t required. The results of the evaluation for the foundation for an (optional) declaration of compliance (see above).
Website operators who want to evaluate the accessibility of their online presence generally concentrate on standard testing methods like WCAG-EM. But the WAI recommends combining the compliance evaluation with a user-based evaluation, as far as possible. This way, operators can identify usability problems that aren’t included in the criteria catalog of the WCAG 2.0.
A user-based accessibility test usually supports people with disabilities as well as older internet users. Informal testing methods in the form of surveys as well as formalised usability tests are also possible, which are based on the statistical evaluation of certain tasks related to the website in question.
Advice on how website operators can involve their page visitors in such evaluation methods is available on the WAI’s information page.
Website operators can find various tools online for the evaluation of the accessibility of their web presence. The WAI also encourages the development of appropriate programs and web services, though a recommendation for a particular evaluation tool can be found on the W3C website. Instead of recommending a single tool, the WAI offers an extensive list of available evaluation tools that can be conveniently limited to fit individual requirements and the desired standard (WCAG 2.0, WCAG 1.0, or BITV), thanks to a filter function.
WCAG in the UK
Currently, most laws dealing with the protection of individuals with disabilities are covered in the Equality Act 2010. This was created to replace old anti-discrimination laws, including the Disability Discrimination Act 1995, and legally protects people from all sorts of discrimination through a single Act. Its provisions on disability outline the requirements that must be met when it comes to adjustments for disabled people, and the GOV.UK Service Manual provides further instruction and assistance on how to help your service meet those standards.
Outlook: WCAG 2.1
WCAG 2.0 is the currently recommended standard by W3C. But the WAI is already working on a new version of the Web Content Accessibility Guidelines: WCAG 2.1 should be published as the new standard in 2018 and replace its predecessor WCAG 2.0. But the WAI assures backward compatibility for website operators. If a WCAG 2.0 website is to be transferred to WCAG 2.1, only a few new requirements need to be considered.
With WCAG 2.1, the WAI aims to improve the accessibility of websites for internet users with limited vision, cognitive disabilities, or learning difficulties. But the most difficult task lies in the accessibility of web content. A working version of the WCAG 2.1 (W3C Working Draft) can be found on www.w3.org/TR/WCAG21