What is Progressive Enhancement and why is it important? How can we make web sites and web applications that are accessible to all users, regardless of the hardware and software those users have? This lesson has some of the answers and shows you where you can find more details specific to the tasks you will be trying to complete in the future.
Progressive enhancement is a design methodology that ensures a web site/application is accessible to everyone, regardless of what kind of device they're using. We do this by separating our application's structure and content from the styling and from the functionality, essentially dividing up the development of any site/application into those 3 components or steps:
Using progressive enhancement, we must design our web site/application in three stages:
The key thing to remember is that your site/application must always be accessible to all devices/users. Added styles and Javascript should only enhance the experience, but should NEVER hinder the experience of any category of user. For example, a user with a screen reader doesn't care about the styling and layout, but the flow of the document should still be accessible to them: the header should still be read first and the footer should still be read last, items in a list should still be read in order, the user should still be able to tab from link to link in a logical order or from one form field to another in an order that makes sense. Similarly, screen readers generally don't support JavaScript, so any JavaScript functionality should only be an enhancement to the main experience, and not a requirement to using the site/application. For example, if you use Javascript to populate a drop-down list of provinces in an address form, a user with a screen reader might see an empty list, and will not be able to choose a province. In that case, you would have to come up with an alternative or option for users with a screen reader.
I'm sure you've visited web sites on both a laptop or PC and also on a smaller device like a smart phone. Have you ever visted a site on your phone and found that it's difficult to use because it wasn't created to be used on a small screen, or it wasn't optimized for your phone? That's an example of bad design, where they didn't design using progressive enhancement.
Developing your site following the PE approach has some advantages:
Read the following articles and then answer the questions below. Write your answers down in your notes in your own words. Understanding these concepts is key to understanding how to develop web sites and applications that are accessible to all users.
It should be obvious that accessible web sites and applications are absolutely vital: In many countries, all software and web-based material and applications required for work and education must be accessible to all users. If a worker or student is hard of hearing, blind, or has mobility issues, or has any other disability, their employer/educator is required to ensure that all software and web content is accessible. If your web site or application ignores a certain demographic of users, a company or educational instituion will not be allowed to use it.
Even if your web project is not required for someone to do their job or learn in their program of study, you should still ensure that your project is accessible. You would not wish to obtain a bad reputation for ignoring the needs of a certain group of users, and you should want to ensure that your site or application is inclusive and usuable to everyone.
When designing a web application or web site, it's important to be aware of what the barriers are. This helps you more efficiently and effectively design an accessible web site/app. When starting a site/app from the start, make it accessible as you develop it: it's much more time consuming to add accessibility later.
There are two sets of standards for web accessibility:
Both of these standards are maintained by the World Wide Web Consortium (W3C)
The WCAG defines the international standard for accessible web content. The WCAG document shows you how to make your web content accessible and provides conformance standards so you can "grade" your web content to see how well it conforms to the international standard. WCAG lists a set of guidelines and success criteria. The guidelines are objectives that you should be trying to achieve when developing an accessible web site. The success criteria are lists of items you can use to test the guidelines to make sure you achieve the objectives of an accessible web site. Finally, the WCAG lists techiques that can be used to meet the objectives of an accessible web site.
WAI-ARIA focuses on rich internet applications, which are web applications that contain dynamic and interactive content/elements, such as those written with JavaScript. This one is particularly important because many users that use screen readers cannot use the JavaScript functionality in a web application: most screen readers can't understand or are unable to execute JavaScript code. Additionally, JavaScript functionality is the most difficult to accommodate: If someone can't use a mouse, how will they be able to manipulate interactive elements in an application? If a user is blind, how can they access the menu system? ARIA defines a set of attributes and techniques a developer can use to make rich internet applications accessible to all users. The biggest challenges are generally endured by those users with visual or mobility issues, but ARIA covers other isssues, as well.
These standards and guidelines are based on the the four principles of accessible web design. I will summarize these below and add some extra comments and information but be sure to click the links to MDN (Mozilla Developer's Network - a great source of up-to-date help and information on anything related to web design and web programming). The four principles are
To perceive, in the context of these tutorials, means to sense or have an awareness something. For example, you are sitting down and you feel something hit your feet, so you look down and you notice that your dog brought you your favourite slippers and dropped them at your feet. Another example: you are petting your cat and you feel the pain in your hand as they swat at you to indicate that they've had enough pets. Perception deals with senses:
A blind person can't perceive an input in a form field is incorrect because they can't see the red border around it. A person with memory issues can't perceive that they are clicking a link they've already visited because the designer didn't change the colours of visited links. A person who is Deaf/deaf can't the instructions in the instructional video because they are being given by a person speaking and there are no captions or transcript.
This section of the guidelines explains how to ensure the content on your web site can be perceived by all users using at least one of their senses.
This section of the guildelines discusses how to provide text alternatives and captions/transcripts for non-text content and time-based content like images, audio/video (live streamed and pre-recored), CAPTCHA, etc. It also describes guidelines for the presentation of content (layout, sequence, colour, scale of items, contrast, text spacing, background audio, etc)
The word "operable" is an adjective that simply means "able to be used". If you spill coffee inside your computer, your computer is probably not going to be operable. If you unplug your microwave, the microwave is not operable until you plug it in again. I have low-vision, so for me a car is not operable (although an autonomous car would be!)
This section of the guidelines states that:
I probably don't have to explain this one, but to make content understandable means that everyone should be able to comprehend the meaning of the content or the message it intends to display.
This section provides guidelines for the language of the content, use of abbreviations, and readling level. It also provides information about ensuring your content's interactive components don't cause "change of context" (drastic change in screen/font size, the cursor doesn't jump to an unexpected place, the document doesn't suddenly scroll to a place that doesn't make sense) that can be disorienting. It also mentions consistent navigation, assistance with input errors (e.g. clear error messages/indicators), and context-sensitive help.
The word "robust" means "strong and sturdy" and "able to withstand adverse conditions" but we often use this word to describe software and hardware that is "hard to break" or "difficult to crash" because such software/hardware is able to stand up to many different conditions (e.g. users with different skill levels).
This section of the guidelines talks about how to ensure your site/application can be used by any "user agent" (e.g web browser, screen reader, etc). If your application is robust, it can be used by people using a standard web browser, or an "alternative" web browser, or a user who uses a screen reader or text-based browser. This also includes user agents with screens of various sizes: large monitors or small smart phone screens. It also provides guidance on ensuring your site or application is still usable with user agents that don't yet exist: new and updated browsers, devices, and other technologies.
There are two very useful tools you can use to check the accessibility of your web pages:
The Accessibility Tree is automatically created by your browser. It contains information about each object in the DOM; in fact, the accessibilty tree is built from your document's DOM.
The items in the accessibility tree represent the various elements/objects in the document. The accessibility tree gives each of these objects some properties, depending on the object type and/or HTML element used to create it:
checked state
if it's checked. Another example: if the object is an input
field and the user has entered data that is invalid, then the
object has a state of invalid.There could be other properties, depending on the element and what attributes it has.
The purpose of the Accessibility Tree is to provide a subset of the DOM that can be used for keyboard navigation and assistive devices such as screen readers. Screen readers aren't actually reading the web page the way you see it with your eyes: The screen reader is moving through the Accessibility Tree and reading out the objects and some of their properties. For example, when the user tabs into an input field containing an invalid input, the screen reader will read out the name of the input field, then "edit" to indicate it's an editable field, then the text inside the field is read out loud, and then "invalid" to indicate that it's current text input is invalid.
As a developer, you should check your page's Accessiblity Tree to make sure that the objects have the names, states, and other properties you are expecting them to. This also gives you a good idea about how users with assistive technologies will perceive your page's content, and how users will navigate the page via keyboard.
WebAIM, a popular name in the area of web accessbility, has a tool called WAVE: Web Accessibility Evaluation Tool (opens in the ref tab/window). You can use the tool directly on its web site by entering the URL of the page you want to check. If your page is in development (e.g. you're still working off your local computer) or you're unable to check by entering the URL (e.g. your page is password-protected), you can install a browser extension.
To set up the browser extension, install it for your browser, then go into your browser's settings for the extension and allow it to view local files (by default this is disabled).
For example, in Chrome I go into Settings > Extensions, then find the WAVE extension and click "Details". Scroll down to the permissions and settings, and toggle ON "Allow access to file URLs".
To use the extension, load a local .html file into the browser. Then click on the WAVE extension icon in your tool bar.
The WAVE extension will open up a window on the left side of your page. It contains 6 tabs:
Both of these tools will help you understand the accessibility of your web site, and also help you find and fix any accessibility problems you might be having.