Overview

What is Progressive Enhancement and why is it important? How can we make web sites and web appliations 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

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 breaking any site/applciation into those 3 components:

• Content/Structure
• Styling
• Functionality

Using progressive enhancement, we must design our web site/application in three stages:

1. Define the content of the page and then use HTML to add the content and the structure of the pages/documents/etc. The content and structure should be viewable/readable in any browser on any device, including screen readers.
2. Add the CSS styling and layout, ensuring that all browsers/devices are still supported, and adding some features for the primary browser/device set. The site should still be viewable/readable to all users on any browser/device, including scree readers.
3. Add the JavaScript functionality to add interactivity, functionality, and enhancements. Users on all browsers/devices, including screen readers, should be supported: the JavaScript functionality should not be mandatory in order to use the site/application. There should be alternatives available for users that can't use the JavaScript functionality.

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.

Accessible Web Design and Development

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.

There are two sets of standards for web accessibility:

• WCAG (Web Content Accessibility Guidelines)
• WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications)

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 or "success criteria" so you can "grade" your web content to see how well it conforms to the international standard.

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):

• Perceivable: to perceive, in the context of these tutorials, means to interpet or understand something. For example, you might perceive that your dog is hungry when she brings you her empty dish, or you might perceive that your cat has had enough pets when he swats at your hand with his paw. You can perceive how important it is to create accessible web sites by going through this tutorial.
  • This section of the guidelines explains how to ensure the content on your web site can be understood/read/interpreted by all users using at least one of their senses.
  • Example: If your web site relies heavily on being able to see, you'll need to add the ability for blind or low-vision users to be able to perceive any content/functionality that they can't see.
  • Example: If your web site uses audio, you must make sure that deaf/Deaf or Hard of Hearing users are still able to perceive the meaning of important audio content on your site (e.g. by providing a text description of the audio).
  • We can assume that the sense of smell is less important in web development, unless of course you're working on some kind of new "click and sniff" application (who knows what kind of technology we will have in 20 years, this item might not age well).
  • 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)
• Operable: "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 all navigation on your web site/application (e.g. menus, links to the various parts of your site/application) and any other user interface components must be operable to all users.
  • This section talks about how to make sure a user can use a web site or application using only a keyboard, that all users are given enough time to read/hear and use the content, that components are easy to find and navigate, and that you design your content such that it doesn't trigger seizures or physical reactions (e.g. things that flash or have too much animation). It also discusses how to handle "path-based gestures": for example, if your application requires that the user drag an image into a carousel-like interface, or that they use two fingers to "pinch". Not all users are able to make these kinds of gestures so your application needs to inculde alternatives.
• Understandable: 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.
  • This section 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.
• Robust: "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.
  • This section 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.

In addition to the links above, another helpful resource is MDN's ARIA page: it summarizes the purpose and contents of ARIA and contains helpful tutorials on how to use ARIA in your web applications.