Talks Tech #31: Accessibility Is Never Done

Women Who Code Talks Tech 31     |     Spotify – iTunes – Google – YouTube – Text

Amy June Hineline, CPACC, Senior Community Manager at Opensource.com, shares, “Accessibility is a Moving Target.” She discusses types of disabilities, agents for accessibility, and the importance of testing for accessibility in every phase of web development.

What is accessibility?

In the context I’m going to talk about, it’s about producing rich, robust content that can be accessed across all our digital assets. Why do we design for accessibility? When they talk about stakeholder buy-in, many folks talk about that it’s the law, but really, we want to include a broader consumer base. We want to have everyone for our content and services. We want to be as inclusive as possible. Something to remember is that not every disability can be seen.

There are things like fatigue or dizziness, learning differences, mental health disorders, debilitating pain, as well as hearing and vision impairments that people usually think about when they think about accessibility. According to the Center for Disease Control, 26% of people living in the US live with a disability. That’s one in four or roughly close to 70 million people. Inclusion is not giving special privileges to people. It’s making sure that the barriers are removed. I want to add that the term “special privileges” or “special needs” is troublesome in itself because there’s nothing special about them; they’re fundamental human rights.

The Americans with Disabilities Act or ADA prohibits discrimination and guarantees that people who have disabilities have the same opportunities as everyone else to participate in mainstream American life. Section 508 requires federal agencies in the United States, to develop, procure, maintain, and use information, and the technology around our communications, making sure that it’s accessible to people who live with disabilities.

The Accessible Canada Act ensures a barrier-free Canada to parliament. It aims to benefit all Canadians, especially those who live with disabilities. The World Wide Web Consortium is an international community that develops open guidelines to ensure the quality and growth of the web. “Open guidelines” means that they take collaboration and they take to comment. They make drafts of all of these guidelines ahead of time and seek community collaboration. One of the guidelines that they work on most is the Web Content Accessibility Guidelines, or WCAG for short.

The goal is to provide that solitary single-shared standard for digital assets for their accessibility. WCAG is broken down into three levels, A, AA, and AAA. With each increasing A, it means that there are more criteria to follow to make your digital assets compliant. That first level, the A level, is really about minimal compliance. If your investments don’t meet at least this level, then it means that it’s challenging for people with disabilities to use.

At the AA level, this is the acceptable compliance level. It means that your website, for most people, is usable and understandable. The optimal compliance level is the AAA level. It means that your website is accessible to as many people as you can possibly make it with or without disabilities. AAA level really indicates the highest level of usability for folks with or without disabilities.

POUR is four high-level principles that functionally describe accessibility. There’s perceivable, which means that the user can identify content and the interface by elements of the senses. Operability means that the user can use the buttons and controls and interactive features, anything that’s interactive. Understandable means we should be able to comprehend the content and learn and remember how to use the interface from page to page or asset to asset. Robust is making sure that people can access your information and assets with whatever technology they want. This includes documents, multimedia, video players, and other informational formats.

We want to make sure that we accommodate visual needs. The Center for Disease Control reports that 12 million people 40 years and over in the United States live with some vision loss. One million people are blind. There are situational or temporary setbacks like cracked cell phones or glare. We want to make sure that our content is easier to interact with. We accommodate motor needs, people who live with palsy from Parkinson’s, or maybe they have paraplegia from ALS or an accident. This also might mean someone with a situational disability, like a mother holding a baby on a city bus, and she’s only got that one hand to navigate her cell phone.

We also need to accommodate auditory needs and that things are easy to hear. When we address these needs, we help individuals who are in noisy environments, as well as our deaf and hard-of-hearing friends. We have folks who might have audio-processing issues and can’t keep up, or maybe English isn’t their first language. When we have captions and transcripts, it really back up that content in another way for people to learn from. The last one is to make sure that you accommodate cognitive needs and make sure that it’s easy to understand. This includes people who are distracted. Lots of folks have a difficult time focusing these days, as well as folks who live with mental health issues and may have limited cognitive functions.

What’s on the horizon?

2.2, and it was initiated with the goal to continue 2.1 but also improve accessibility guidance for more groups. We include users with cognitive or learning disabilities and more standards around folks with low vision. 2.2 is everything that 2.1 had to offer, plus nine new items. No matter what guidelines are coming, it’s our responsibility as web designers, developers, content authors and anyone who cares about digital accessibility to keep track of what’s coming next.

The Accessibility Guidelines Working Group recommends that we start adopting 2.2 as our new conformance target, even if our formal obligations mention previous versions, it’s to provide improved accessibility and to anticipate future policy changes. There’s also 3.0. This presents a new model and a new set of guidelines to make web content and applications accessible and support a wider group of user needs. There are new approaches to testing, and 3.0 really allows frequent maintenance of guidelines and related content to keep pace with the constantly changing technology.

3.0 supports this evolution by focusing more on users’ functional needs and improving the accessibility of products across a variety of platforms. So 2.2 and 3.0 really change things up. It’s a little bit about the way we think about the guidelines. We’re taking into account more disabilities. We’re thinking about cognitive disabilities moving forward, and that wasn’t something that we considered before. We want to be able to apply more technologies than just the web. These guidelines are opening up space for things like augmented reality, voice assistance, and virtual reality. We want to consider all the technologies people use, including the tools that help our web authors. Are our backend administrative interfaces accessible? What about our media players and our browsers? 3.0 expands the scope of the current guidelines.

Accessibility is not static. It’s dynamic. It’s never finished. It’s constantly changing. We need good sources of information in our tool belts. This can be attending a session, attending an online meeting, or subscribing to newsletters. Do your research and find credible sources of information, and take the time and add them to your weekly reading list or your professional development time. User agents are assistive technology. Sometimes we’ll see it as “AT” for short. It’s any device, software, or equipment that helps people work around challenges they have in learning, communicating, and functioning on the web.

Screen readers are used to listening to the content of a web page or asset. They convert text to speech. Screen readers can be used alongside visuals on the web page for folks with cognitive challenges as well, not just for our blind or low-vision folks. Screen magnification software is true to its name. It’s used to enlarge the content on the screen. It’s easier for us to read, especially if we live with partial sight impairment, it’s used by people to enlarge the content, but screen magnifiers also have text-to-speech functionality. Eye tracking, sometimes called eye gaze,  is a system that monitors eye movement to control a mouse pointer.

Accelerators are software and functionality that help reduce the effort needed to type or click. You might be familiar with sticky keys. This goes along the lines of keyboard customization. Pop-up and animation blockers, refreshable braille displays, and reading assistance are other agents used for accessibility.

Look at the lifecycle of a website. We draw up wireframes, and we do research while getting stakeholder input. Research gets passed on to the user experience folks and the design team. The developers get involved. The QA person might be adding placeholder content because it’s hard to test whether or not your site functions if you don’t have content. Then there’s the stakeholder handoff, and the site has popped out on the other side, leaving the content creators and the editors to finish the site before launch.

All those tasks in the life cycle, have people with specific assigned roles to perform the task. There are the designers, front-end developers, back-end developers, QA people, product owners, stakeholders, and editors. We must ensure that we’re giving all of our roles accessibility responsibilities, not just our QA or “accessibility people.” We want cross-functional teams. We must empower our designers and people doing the research to have accessibility in mind from the start. Fixing an issue in production is much more complicated than in the design phase. We also want to think about our editors and our content creators. We want to empower our content authors and set them up for success. If we train our developers and our designers on accessibility, then why not train our content creators as well? We want to make sure that everyone is really involved in that accessibility process.

We test for accessibility at all the phases of development, or better yet. We bake accessibility into our websites from the beginning. Accessibility is never finished; we want to ensure that we strategize and develop in a way that allows flexible changes as the guidelines evolve. Have retrospectives with the whole team. Do you have accessibility reviews and audits as part of your flow? Continuous website improvement can be challenging at first. Design and content creation can be similar, but they happen at many different times in the website’s life. Design is before launch. Content can occur at all phases.

For optimal readability, we want to utilize visual and semantic space. Space is an underutilized graphic design tool that helps us identify groups of related content and delineate unrelated content. We want to provide the right amount of space between lines of text. For most content to work, the inner line spacing is applied automatically in our CSS. We want to use clean topography and to avoid changing the typeface specified by the website. We want to make sure that it looks the same from page to page.

When we write in all capital letters, readability is reduced because all of the words now have a uniform rectangular shape, meaning that readers can’t identify words by their shape. We don’t want to underline text, we really want to reserve this for identifying links. We don’t want to center-justify our text, we want to left-align our text because that consistent left margin makes reading easier. Leftover from our typewriter days, we don’t want to put two spaces after a period. When we’re talking about assets on the web, we use one space, period. We want to support text resizing. We take a lot of time to make sure our code is accessible, but what happens over time when content is added? This is one of those moving targets, especially when a team of people is involved. It is something that is more straightforward to remedy.

Accessible content can be an easy win when you go to remediate a website. Content is entered at every step of the life cycle. You want to know your audience. Put information in a logical order, important details first. Fit your language to your audience and context. Really stick to predetermined reading levels. The guideline for general content is the ninth grade reading level in the United States. It’s even lower in the UK. There are exceptions to this. Use familiar language and familiar combinations of words. Writers should strive to communicate with their readers, not impress them with showy words. Be consistent with the words that we use.