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:
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.
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.
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.
Exercise
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.
What is graceful degradation, and how is it
different from progressive enhancement?
What are the four major reasons for developing with progressive
enhancement in mind? Make sure you're able to briefly explain
each in your own words.
What is WAI-ARIA (not just what it stands for: what is it, what
is its purpose)?
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:
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.