Graceful Degradation vs. Progressive Enhancement

Given the range of support for WAI-ARIA across current screen readers and browsers, strategies like graceful degradation and progressive enhancement are useful for accommodating varying implementations and ensuring that tools developed with WAI-ARIA are accessible regardless of support.

Depending on your situation, one development method may be preferable over the other, though in general progressive enhancement is preferred over graceful degradation. That is, creating base functionality that works for everyone is preferred, rather than providing enhancements when they are supported by the browser and/or assistive technology. Graceful degradation, on the other hand, starts with the enhancement, then provides alternatives where the enhancements are not supported. While they may sound equivalent, the latter typically requires less effort, even though it is more of a Band-Aid solution to correct an incompatibility. The former takes a little more effort and is more about providing enhancements when they are supported while always providing a base functionality that works for everyone.

Definitions

In his article, “Graceful degradation versus progressive enhancement,” Christian Heilman provides some useful definitions that help distinguish between the two methods:

“Degrading gracefully means looking back whereas enhancing progressively means looking forward whilst keeping your feet on firm ground.”

When to Use Which Method with WAI-ARIA

Though progressive enhancement and graceful degradation are development methods that might be followed on any web project, here, we talk about them as they relate to the use of WAI-ARIA.

Support for WAI-ARIA is improving constantly, but there are still many inconsistencies between browsers and assistive technologies. And there will still be those using older assistive technologies that were around before WAI-ARIA support was added. Because assistive technologies tend to be expensive, users tend to upgrade less often, thus it is important to support technologies that may be five years old or somewhat older.

Browsers, on the other hand, are typically free, and readily available. However, that does not necessarily mean developers can rely on users having the latest or even a current browser. It is not uncommon, particularly in large organizations, to restrict employees’ ability to upgrade their own systems.

A simple example of progressive enhancement (though it could also be seen as graceful degradation) is in within–web page navigation for screen reader and keyboard-only users. Before the advent of WAI-ARIA landmarks, the way to provide this within-page navigation was to provide bypass links, which would typically be located at the top left of the page. These bypass links lead to strategically placed anchors, often next to navigation elements and at the top of the main content area. These links are standard HTML and will work for everyone. WAI-ARIA landmarks are relatively new, though support for them in current browsers and assistive technologies is good. But, given some users will be using older technologies, at least for the short term, it is advisable to provide landmarks as an enhancement and continue using bypass links to ensure there is always a way to navigate effectively through web content.

Similarly, when using the newer HTML elements that may not be supported by current assistive technologies, it is a good idea to use redundant roles, at least in the short term. For example, <nav> and <main> are new HTML elements, which are supposed to be equivalent to the navigation and main WAI-ARIA roles. However, not all ATs support the new tags at present. Thus, it’s advisable to use redundant roles with these elements, as seen in the markup below, even though HTML validators will flag them as a warning.