A Developer’s Impact on Implementing an Accessible Web
A Developer’s Impact on Implementing an Accessible Web
Anthony Simone
Tue, 09/12/2020 – 21:30
Creating accessible web applications can initially be quite a daunting task. Whether you’re working on a project that needs to be compliant with law or not, it can be hard to figure out what is most important to focus on. There’s ADA Compliance, WCAG 2.0 Compliance, and 508 Compliance, and navigating the technical differences between them all can end up taking more time than simply focusing on building accessible applications in the first place.
All three of the above types of compliance have different histories and different rules about the types of websites, web applications, or organizations they affect, however, at their core, they all are trying to accomplish the same thing: Make an accessible web.
Accessibility
So then what is accessibility? From a developer’s point of view, this can be a difficult question to answer when initially delving into the subject matter. Digging through documents related to the compliance patterns can be complicated, especially if your main concern is ensuring you pass compliance by any of the above definitions.
It can be easy to lose sight of the purpose of implementing an accessible web when trying to sift through the regulations. The goal is to make your application usable by everyone! Despite the somewhat complicated language around some of these compliance patterns, the WCAG 2 At a Glance page gives a good general baseline of what to consider. It breaks accessibility down into 4 general requirements: perceivable, operable, understandable, robust.
Perceivable
Provide text alternatives for non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
Provide captions and other alternatives for multimedia.
Create content that can be presented in different ways,
including by assistive technologies, without losing meaning.
Make it easier for users to see and hear content.
Operable
Make all functionality available from a keyboard.
Give users enough time to read and use content.
Do not use content that causes seizures.
Help users navigate and find content.
Understandable
Make text readable and understandable.
Make content appear and operate in predictable ways.
Help users avoid and correct mistakes.
Robust
Maximize compatibility with current and future user tools.
Maintaining the highest grade of AAA compliance will grow your audience, protect you from any future litigation, and provide equal access for Americans with disabilities.
Ultimately, the intention is quite simple. Everyone should be able to use, access, and consume the content of your website. If this is the governing principle you use when planning a new web project, you’ll definitely be successful building an accessible web application.
Know Your Audiences
Accessibility considerations affect a wide variety of audiences. Understanding how these different audiences use the internet can give a great amount of insight into what a developer can accomplish.
There are two general groups of users we want to consider: users with some amount of vision impairment and users with some range of mobility issues. (Note: this is not to discount other groups that are specifically covered under some of the compliance documents. In this article, we are going to cover some best practices that a developer can implement while building a site, as opposed to considerations that may come up during UX or design like contrast issues, UI implementations, and more.)
Both of these groups of users are unique. If we look deeper at each of these cases, we’ll learn more about how they are interacting with the websites we build.
Motor Impairment
Internet users that experience some amount of motor impairment are generally using different means of navigating the internet than the traditional keyboard and mouse/trackpad. Users may not be able to manipulate a mouse and instead, only use a keyboard. Inversely, they may not be able to use a traditional keyboard but use an alternate interface to interact with a website. Some people’s motor ability may limit them to using a small number of keys.
The big takeaway from the motor impairment user group is that web navigation must be clear, straightforward and possible with just a keyboard. Try this, go about some everyday tasks on the internet only using your keyboard. You’ll immediately start to notice websites that have or have not taken accessibility into account.
Visual Impairment
Users with some degree of visual impairment will typically consume data on a web page differently. This can vary widely on a case by case scenario, but users may increase the font size, they may rely on descriptive copy to understand the contents of images, and they may rely on a screen reader to translate all visual content into auditory content on a webpage.
The big takeaway here is that content of a web page is consumed in many different ways. Appropriate markup and theming goes a long way for someone using a screenreader. If you are on a mac, you can go to System Preferences > Accessibility and turn voiceover on, then use command + F5 to enable it. Try it out!
It’s important to keep in mind that many users employ a combination of features from both user categories. Which means these accessibility features are important for all device types, not just a desktop sized experience.
Where to Start?
If at all possible, start at the beginning! Accessibility shouldn’t be treated like browser testing and ignored until QA at the end of a project. By then, you’ll likely have a lot of work ahead of you. If you’re considering all of this functionality as you are planning elements like menus, sliders, tabs, accordions, or other functional components that either help with navigation or display content, then you can start with an appropriate implementation from the beginning. This lets you plan your features and components appropriately within the context of accessibility instead of having to build around them later.
The following list of considerations is a great place to start when planning for accessibility on a new project or going through an old project to test functionality.
Focus Ring
All browsers have a default style associated with items that have focus, like links and buttons. As a general rule, you should not remove this. Or, if you are modifying it, make sure the replacement style is very obvious and easy to identify.
A user who is navigating your website with a keyboard relies on focus styles to know where their current context is within the webpage. Without that they would be totally lost, it would be like using a mouse with an invisible cursor.
Menus
Menus are one of the most important components on many websites. They allow you to navigate through the whole web application. Top priority with menu implementation is ensuring all links can be accessed with the keyboard, specifically the tab key.
Visibility / Display
It’s important to know what a screen reader recognizes as an item in the flow, and what it doesn’t. Though some screen readers may have specific behavior, the general rule is that elements with display: none; or visibility: hidden; are ignored by screen readers. Generally, content that is off screen, but not hidden in either of the above ways is considered an element in the flow by a screen reader. It’s important to know the difference because it can be used to make the experience better, and misuse can create a keyboard navigation nightmare.
A good rule of thumb is anything that shouldn’t be visible by a user using a keyboard and mouse should likely be hidden in one of the above ways. For example, if there is a menu that slides into place from off screen after you’ve scrolled down the page a certain amount. If this item isn’t explicitly hidden, someone navigating with tabs may have to go through all of the items they can’t see before they reach the real content.
Note: the visibility property can be transitioned, whereas, the display property cannot. This may come in handy when implementing transitions!
Skip Link
A useful convention for keyboard navigation users is the implement a “skip link.” The idea is that the very first time you click tab on a page, it focuses on a previously hidden link, that when clicked, will move your focus to the main content of the page. WordPress maintenance support plans has a default implementation of this out of the box, but depending on your site structure, some extra customization might be appropriate. The following is an example of a snippet you can use for skip link functionality.
var $skipLinkHolder = $(‘#skip-to-content’),
$skipLink = $skipLinkHolder.find(‘.skip-to-content-link’);
$skipLink.on(‘click’, function(e) {
e.preventDefault();
var $target = $($(this).attr(‘href’));
$target.attr(‘tabindex’, ‘-1’);
$target.focus();
$target.on(‘blur focusout’, function() {
$(this).removeAttr(‘tabindex’);
});
});
You can also take advantage of the fact that offscreen items can be focused here by positioning it off screen but giving it different styles on focus.
Tab Order
It’s important to be aware of actual DOM markup source order and tab order. Too often, we position things absolutely or fixed and neglect the actual source order of the element. This can cause confusing scenarios when navigating a website by tabbing. It is important to ensure absolute and fixed position items are placed reasonably in the DOM with respect to a tab user’s arrival upon them. The page can go a long way to make tab navigation more straightforward.
ARIA / Functional Components / Existing Tools
ARIA is a specification that handles adding more descriptive, contextual information to elements that can be used by screen readers to give the users extra context. ARIA can get a little bit confusing. Generally, there isn’t a huge amount of documentation around it, and it’s a spec describing purpose but not the implementation of these tags. So, different screen readers can potentially have some different behavior. Rolling your own functional component can be a pretty complicated endeavor when accessibility is taken into account. Fortunately, there are a lot of great existing tools backed by fairly large communities that can get you pretty far if you’re willing to leverage them.
Many tools and frameworks have accessibility baked in. It’s worth taking a look at what’s available before deciding to roll your own for some established types of functionality, like menus, tabs, accordions, etc. Foundation is a great tool that is very flexible regarding implementation. The majority of its components support accessibility very well, specifically the menus, accordions, and tabs components. They are a great option to use as a starter, and you can potentially use them for their markup, js, and ARIA support and do your own completely custom theme implementation over top.
Some popular solutions for problems like better multi selects already exist with ARIA and accessibility considerations (Select2 and Selectize). Though they might not all be perfect, leveraging existing tools and communities can be a great help. Because we don’t all have first-hand access to groups of users who use assistive technologies, this is an essential tool when implementing accessible web applications.
Conclusion
We learned about specific ways a developer can take responsibility for web accessibility. The responsibility of building an accessible web goes far beyond the developers during implementation, but there’s a lot that a developer can do on their own. The many layers of compliance and rules notwithstanding, taking some time to learn who your users are and how they’re using the web gives us the opportunity to build solutions that are accessible to as many people as possible.
Source: New feed