Global ecommerce brands delivering accessible user experiences to web and mobile users have an advantage over non-competitive brands. For starters, savvy brands recognize a largely untapped market segment – consumers with disabilities and consumers over the age of 65. However, there’s a misconception about these two consumer segments: they have limited spending power. Quite the contrary. 

Who are these consumers? 

People with disabilities shop online twice as often as the general population according to Fable. In the U.S. alone people with disabilities have 1.3 trillion in disposable income according to research by the Return on Disability Group. By adding the spending power of their friends and family it’s a hefty $13 trillion.   

And let’s not overlook the wealthiest cohort in recorded human history, consumers 65 and older (Boomers) aging into disability. According to the U.S. Census Bureau, 17.7% of this consumer population is a “spending force to be reckoned with.” Also noted in the Wall Street Journal.  

And these well-heeled consumers with outsized spending power are expected to live to age 79 and willing to spend on discretionary items. Understanding and appealing to older online consumers gives accessible brands opportunity to cement a long-term relationship with them. This also is true of consumers with disabilities who tend to be loyal to accessible brands. As a result, online services are essential and need to be accessible to realize the benefits of spending power. 

Actions to start in 2025 

1. It’s never too late to gain ground on competitive brands, and particularly brands with no foothold with these two consumer groups. Offering accessible user experiences and services to delight them is still a greenfield, and it will be for some time.  And there is another benefit to brands designing and delivering accessible digital experiences known as the curb cut effect. As brands look for ways to deliver accessible mobile and web experiences to a general population of consumers, the net effect is better user experiences for everyone (e.g., easy to use, easy to find and understand information). 
2. Embed inclusive design in your core product at the start of new designs to create accessible user experiences. It’s easier for design and development teams to implement, and it reduces refactoring time to fix issues found downstream in the quality assurance (QA) stage. Also, it minimizes barriers to entry for people using assistive tech such as a specialized keyboard, screen magnifier or a screen reader.  

As your team designs for an accessible user experience be mindful that your go-to resource should be the Web Content Accessibility Guidelines (WCAG) of the W3C, the global organization defining and overseeing web standards. Those Guidelines will be technically sound and used by practitioners across the globe, minimizing risk of non-compliance. However, these standards may not ensure compliance if an organization is not including the ‘right’ consumers in user research – particularly those over the age of 65 and those with disabilities.  

1. To satisfy and delight both groups, engage them in usability studies. This is a pragmatic and low-cost way to obtain insight about the user experience of your application, UI components within an application and so on. And this form of research can be quite affordable and effective. My colleague Samdisha Singh and I shared insights with Nate Brown from Userlytics on the benefits of including consumers with disabilities in usability studies. By partnering with the Userlytics testing platform, insights about a new design or redesign can be obtained on the spot. Design teams start implementing changes into user flows and user experiences literally the same day.  
2. With research findings at hand, it’s time to brainstorm with your design team. Consider which inclusive design choices benefit consumers with disabilities and will also attract consumers without disabilities. For example, when a design meets WCAG color contrast requirements, it satisfies a broad range of consumers (as mentioned the “curb cut effect”). Not only does it make viewing a web page or mobile apps easier for people with color blindness, but keyboard users also benefit. These users rely on “focus appearance” to identify where they are as they tab through a screen. 
3. Invest in upskilling your design teams. They are at the ‘top of the funnel’ when it comes to making accessible design decisions. And ensure they use their expertise and work closely with the user research team. Interpreting user feedback and making design decisions should be collaborative. 

Still unconvinced? 

Many sources cite roughly 1 billion people globally have unreported and invisible disabilities. Take for example CEOs, they are behind some of the most successful global mega brands and approximately 30% are dyslexic. The bottom line, with a clear understanding of the needs and aspirations of online consumers over the age of 65 and consumers with disabilities, your brand is at an advantage over brands uncommitted to accessible user experiences.   

Additional Resources

Perficient Experts Interviewed for Forrester Report on Accessibility for Better CX and EX 

Guide: Digitally Accessible Experiences: Why it matters and how to create them 

Guide: Driving Inclusion in Financial Services with Digital Accessibility 

Guide: Enhance Digital Health Experience with Digital Accessibility 

Perficient Insights: The future of UX is Digital Accessibility 

From Accessibility to Profitability: Maximizing ROI with Inclusive Design Practices 

Creating inclusive and multilingual websites is complex but not without its benefits, especially to multilingual web users with disabilities. In Megan Jensen’s ‘kick off post’ on cultural inclusion she notes that “Undertaking a global multilingual website can be an intimidating and overwhelming project but it doesn’t have to be.”

We’ve outlined specific ways to deliver content to web users with or without disabilities, and to support their language of choice in ways they can understand. Here’s your get started guide.

Assuming is good. Knowing your web users is better!

Designing multilingual and inclusive web experiences takes “culturally-inclusive user research” says Jensen. Start by asking questions about people coming to your website. Where are they located? Which web pages do they engage with the most? What are their most frequent web transactions? Do they use the English version of the website instead of one in their native language? Why is that? And how frequently do they use translation apps? Do they only use a keyboard to navigate web pages? Are screen readers like VoiceOver for Apple iOS or Android’s Talkback used by a significant number of web users?

It’s worth noting that researcher bias comes into play here. My mantra is forget assumptions about the ideal web user who never encounters issues accessing online information. Every web user experiences barriers. They encounter words never heard before, jargon, acronyms and so on. Again, arm you and your team with target audience insights to ensure inclusive language experiences.

Keep it simple stupid “KISS”

For one, always consider the “understandability” of your multilingual and inclusive user experiences. Start by asking a series of questions. Does content appear in predictable ways across our websites? For example, if a link to the organization’s Site Map is in the home page Footer, this link should be in the Footer of all web pages.

And two, help web users by following familiar design patterns. This simplifies the learning curve, especially for web users with cognitive disabilities.

Appearance matters

How information appears on a web page influences web users’ ability to grasp information easily and accurately. Complicated user interactions and esoteric confusing language will waste users’ time. Note, I crossed out esoteric to make a point, “confusing” is a common term and easier to understand.

Text overlaid on images (a common design technique) makes it difficult to perceive and then act on information, especially when it’s not in your user’s preferred language. Take this example. In left-to-right languages (LTR) it is customary to visually position labels to the right of radio buttons and checkboxes, and to the left or directly above other form fields. Maintaining this practice increases predictability and understandability of your form for all web users​.

Designing page layouts for right-to-left (RTL) languages requires a different approach. “Spatial design changes are necessary when localizing for RTL languages (including navigation, visuals, general layout, etc.).”  For starters text alignment adjustments must be made. Apple’s best practice, “Align a paragraph based on its language, not on the current context.”

Also think about the font size and legibility of your default language. For low vision web users, legibility is critical. For instance, a legible font size in English, German, and French could be too small for Japanese and Arabic languages.

Getting into the code and “declaring” language

If most of your website users are native English speakers start by setting the language of the content for English. For example, the primary language of the page should agree with the human language of the page. On the other hand, if most of your target audiences speak French the primary language of the page would be French, to agree with the human language of the page. Comprendre?

There are times when a page has content in another language, so you add a language attribute to an element surrounding that content (see item #2 below). Also, identifying the language of your content (i.e., “lang” and sometimes “xml:lang”) prepares the web page to do a number of things such as change the look and behavior of a page. And include language information for a page at the start. It’s difficult to retrofit it as you develop content.

Three essential guidelines from the World Wide Web Consortium (W3C):

1. Use the html element (<html lang=”en”>) rather than the body element since the body element doesn’t cover the text inside the document’s head element.

• Note: “en” is English.

2. When the page contains content in another language, add a language attribute to an element surrounding that content. This allows you to style or process it differently.
   • For example: <p>The title is “<span lang=”fr”>Le Bon Usage</span>”.
3. Use the lang attribute for pages served as HTML. For pages served as XML, including XHTML 1.x and HTML5 polyglot documents, see Choosing the right attribute.

If you’re designing for a global organization with several multilingual websites, provide links to the other language versions of your site.

And when a web user is accessing your English language site with a screen reader, give her advance ‘warning’ she is following a link to a page in a different language. You would use the ‘hreflang’ attribute as: <a href=”” hreflang=”fr”>French</a> for that situation.

Rules of thumb to keep handy!

The W3C’s Web Content Accessibility Guidelines (WCAG) are the go-to resource to create inclusive digital experiences for multilingual website users. Here are best practices to consider:

• Suggest a translation app or provide one
• Remove, or rewrite jargon, unfamiliar and unique terms
• Provide the meaning of abbreviations
• Indicate how to pronounce words (if it’s key to interpretation)
• Write short, clear, and simple content (typically, at the sixth-grade level)
• Provide glossaries and on-page help text when specific terminology must be used
• Allow web users to add their preferred language to a virtual meeting
• Provide non-text alternatives (e.g., graphs, charts, icons) or audio to increase comprehension
• Make live and prerecorded video transcripts available in multiple languages for download
• Write inclusively (e.g., older person, not senior or senior citizen)
• Avoid text overlaid on images (not easily interpreted by multilingual and low vision web users)

Hmm, you don’t say

English is the most widely used language on websites (59.3%). However, non-native English speakers must be considered too. These web users include the most spoken languages in the world (e.g., Mandarin Chinese, Hindi, Spanish, French, etc.). For them, access to information might be out of reach. Our advice is to think inclusively!

Resources:

• https://www.w3.org/International/questions/qa-html-language-declarations
• https://www.w3.org/TR/WCAG21/#readable
• https://www.w3.org/International/questions/qa-lang-why

So, What Comes Next?

To obtain more insights on creating a multilingual website on SiteCore Compostable DXP, follow Megan Jensen’s series.

The future of UX is digital accessibility, and Perficient has information to help. Download our guide Digitally Accessible Experiences: Why it Matters and How to Create Them, and there’s more to read on digital accessibility in our UX for Accessible Design series.

About the Author

Lisa McMichael, Senior Manager of Digital Accessibility at Perficient, is a Certified Professional Accessibility Core Competencies “CPACC”. She leads and evangelizes inclusive design for Perficient and its clients.

Final installment of a 4-part series

Recently I came across a comment from Lori Samuels, Senior Director of Accessibility at NBCUniversal, that stopped me in my tracks, “You can’t test your way to great user experience, you have to design your way there.” I completely agree. On the other hand, evaluating user experiences for accessibility plays a pivotal role. Testing ensures people with disabilities can access web content. Plus, you cannot create usable and accessible web content without it. These tips will get you started.

Tip #1 – User Testing is a Must

Satisfying user experiences start by understanding your key target audiences, and the most effective method is user research – involving people with disabilities in your usability evaluations to uncover usability and accessibility issues. Also, test responsive designs with them! A user interface (UI) component – for example a carousel – may look and behave predictably on a large monitor or laptop. However, when it is viewed on a mobile phone, you may see design flaws. For example, buttons appearing too close to each other cause web users to accidentally activate the wrong target. Imagine this scenario, you intend to tap “Cancel” and accidentally tap “Submit” instead.

Keep in mind website users with disabilities are not one size fits all. They use technologies in various ways and in different situations. Read the user story of Ali, a young woman with a mix of disabilities and technology usage to shed light on how to design for inclusion.

Tip #2 – Test with the Web Content Accessibility Guidelines (WCAG 2.1 A, AA)

WCAG 2.1 is the international standard to evaluate web pages, UI components, interactive media and videos. These guidelines include 50 Success Criteria with 30 of them labeled “A” level. This level offers the most benefits for digital access. And, it affects the broadest group of web users. When “A” criteria are ignored, web users cannot access web content.

The 20 “AA” Success Criteria is also necessary. It establishes a level of accessibility to work with most assistive technologies (i.e., text to speech screen readers VoiceOver and NVDA) on desktop and mobile devices.

Tip #3 – Automated Testing

Approximately 30-50% of accessibility issues can be detected by an application or browser extension, no human inspection needed. These handy tools will pinpoint issues within a minute of inspecting a web page. Also, they provide WCAG 2.0 / 2.1 Success Criteria based recommendations.

Some popular automated tools are WAVE, aXe, ARC Toolkit, and Accessibility Insights for Web. Keep in mind though, they do not catch all accessibility issues. To identify all or most accessibility issues on a web page manual inspection is a must.

Tip #4 – Manual Accessibility Testing is a Must

The auditors in our U.S. Accessibility Delivery Center routinely inspect web pages manually. “We test a web page by keyboard tabbing through the page and with the assistive technology app NVDA”, says Perficient Senior Consultant Samdisha Singh. “We make sure all front-end code is semantically correct by inspecting the HTML. Is it accurate? Does it have all the correct attributes an assistive technology user needs to interact with it?”

Tip #5 – Quality Assurance (QA) Testing

It’s likely accessibility issues will escape automated and manual testing. It could be last-minute edits made to UI components, or the addition of new content (e.g., PDFs). That’s were QA testing comes in. QA auditors check web pages, UI components, videos, etc. to verify they are indeed accessible and meet specified acceptance criteria.

Tip #6 – Final Advice

Accessible user experiences are becoming the norm and not a nice to have. User research, usability testing and the other forms of testing are essential to satisfy Web users’ expectations for equal access. If you have not read the earlier posts, check out Part 1 Plan to be Accessible by Design: Accessibility in the Product Development Lifecycle, Part 2 Define Initial Requirements: Accessibility in the Product Development Lifecycle, and Part 3 Designing for Diversity: Accessibility in the Product Development Lifecycle.

So, What Comes Next?

For those businesses looking for insights on website accessibility, Perficient has created a set of information to help. Download our guide Digitally Accessible Experiences: Why It Matters and How to Create Them and read our UX for Accessible Design series.

To jumpstart your website’s digital accessibility our Accessibility IQ^sm identifies and corrects website accessibility issues in two weeks, not months.

For more information contact our digital accessibility experts today.

Increasingly, topics like digital responsibility are entering the conversation around digital transformation.  “This responsibility has evolved from primarily focusing on data privacy to now include accessibility, diversity, and inclusion as well. Really, it’s about being more proactive, less reactive. You want to take it from being aspirational to ground truth – how do we make this happen, how do we address some of the concerns, how do we meet consumer and employee expectations, and how do we even understand what those expectations are today,” shares Kim Williams-Czopek, director of digital strategy at Perficient.

Accessibility of digital experiences is receiving more focus and adoption now. An indication is that more organizations buying tech are committing to accessibility in 2022 due to the increasing number of businesses creating diversity and inclusion programs which include providing various forms of accessibility, such as equal access to websites for persons with disabilities.

Also in 2022, accessibility has become an essential responsibility. Earlier this year, the Department of Justice released a statement advising that all businesses open to the public prioritize website accessibility, so persons with disabilities can access vital website content. And it points to a number of entities, including hospitals and medical offices, which have the responsibility to “keep pace with the rapidly changing technology of our times.”

Considering Unique Challenges

Healthcare organizations play key roles in offering access to care, employing, and motivating skilled workers, and acting as social safety nets in their communities. They, along with life sciences organizations, serve on the front lines of addressing health equity.

To reach all consumers where they are, which is increasingly online, mobile, and outside of traditional care settings, it’s important to consider the diverse user stories and unique challenges that may impact how website content is accessed by persons with disabilities (now 1 in 4 in the United States). To understand those unique challenges and stories, we need to ask questions such as:

• How easy it is for anyone to access medical treatments, symptom checkers and providers?
• Have we included captions, audio descriptions and transcripts within our live and pre-recorded videos for people with hearing loss and dyslexia?
• Is our healthcare content written so that anyone can understand it?
• Do we have forms missing descriptive labels and instructions?
• Will our error messages help our website users avoid clicking on the wrong button?

Here are some important best practices and essential Web Content Accessibility Guidelines (WCAG) for making digital experiences accessible for website users:

Situational Challenges

Confusing medical or industry jargon and/or using complex sentences limits accessibility.

• Write in plain language, for the sixth-grade level, noting that many healthcare users are not native English speakers
• Write inclusively (older person, not senior or senior citizen)
• Write person first (people with autism, not autistic people)
• Remove idioms and jargon
• Provide a glossary (or on page help text) when specific terminology must be used

Temporary Impairments

An accident limits the ability to navigate a mobile device.

• Design for keyboard users
• Design for voice search
• Give users alternatives to drag and drop interactions
• Avoid swiping motions (use tap instead)

Health Conditions

Pain, fatigue, memory loss, etc. can impact the duration of web use.

• Design simple interactions
• Reduce or eliminate scrolling
• Design pop-ups and alerts near the visual focus
• For mobile, avoid both horizontal and vertical scrolling (e.g., carousels)

Changing Abilities

Some accessibility features are needed one day and not another day.

• Provide captions and transcripts for all videos
• Suggest a translation app or provide one
• Enable zoom text to 200%

Multiple Disabilities

Disability comes in combinations such as hearing loss and low vision.

• Design for screen reader users
• Enable zoom text to 200%
• Support users wishing to customize fonts, colors and spacing

READ MORE: Diversity, Equity & Inclusion (DE&I) in Healthcare

Healthcare Leaders Turn to Us

Perficient is dedicated to enabling healthcare and life sciences organizations to promote diversity, equity, and inclusion within their companies. Our healthcare practice is comprised of experts who understand the unique challenges facing the industry. The 10 largest health systems and 10 largest health insurers in the U.S. have counted on us to support their end-to-end digital success. Modern Healthcare has also recognized us as the fifth-largest healthcare IT consulting firm.

We bring pragmatic, strategically grounded know-how to our clients’ initiatives. And our work gets attention – not only by industry groups that recognize and award our work but also by top technology partners that know our teams will reliably deliver complex, game-changing implementations. Most importantly, our clients demonstrate their trust in us by partnering with us again and again. We are incredibly proud of our 90% repeat business rate because it represents the trust and collaborative culture that we work so hard to build every day within our teams and with every client.

With more than 20 years of experience in the healthcare industry, Perficient is a trusted, end-to-end, global digital consultancy.

So, What Comes Next?

For those businesses looking to obtain more insights on website accessibility, Perficient has created a set of information to help. You can download our guide Digitally Accessible Experiences: Why it Matters and How to Create Them and request more information about our Accessibility IQ^SM, a jumpstart website evaluation. Also, there’s more to read on digital accessibility in our UX for Accessible Design series.

Contact us to discuss your organizations specific needs

About the Author

I’m a Senior Manager Digital Accessibility with the Detroit business unit.

Product teams should be keen to understand how people interact with digital content and media. For one, web users’ interactions with website content changes over time. Two, it changes by situation. And three, it changes by ability. For example, what a web user can do in her 20’s, such as navigating web pages with a mouse, is impossible later in life. When teams overlook these factors, they inevitably create inaccessible experiences for all web users.

So where to start?

Product team members must adopt the W3C’s four “POUR” principles of inclusive design (perceivable, operable,understandable, and robust). These principles are the foundation of accessible web design. It helps product teams empathize with web users with disabilities. And it guides teams to design for their adaptive strategies, abilities, and assistive technologies.

At first designing with these principles in mind is challenging. Keep these shortcuts handy to make inclusive digital experiences. They are not every example though! Visit the W3C’s site for a complete analysis of POUR.

• Perceivable: Content is presented in more than one format (e.g., an image, diagram, icon, etc.). Provide transcripts. Use simple layouts.
• Operable: Functionality is available by keyboard and other input types (e.g., a mobile phone, mouth stick, etc.). Give users enough time to read and use content. Give users control over motion (e.g., carousel, video, etc.).
• Understandable: Content is clear, familiar, and simple. Web pages look and work predictably (e.g., links presented consistently). Help users avoid and correct their mistakes (e.g., an error message).
• Robust: Maximize fit with current and future technologies like different screen readers (e.g., VoiceOver, NVDA, Talkback, etc.)

Next, obsess over users’ behaviors

People have different interaction styles and settings, preferred operating systems and browsers, and various input methods (e.g., touch, voice, etc.). Start by asking a series of questions. Which user experiences do they want improved and barriers removed? Which technologies do they use? How and why are they using them? Take a look at the User Story of Ali. It’s a snapshot of designing for disability.

Also consider these essential questions. Keep them handy and refer to them often:

• Is web content presented in more than one format in our user interface designs? Can our web users access it from different devices and through voice, vision, touch and/or hearing?
  • In other words, are web pages, user interface components, and content perceivable and robust?
• Did we add transcripts, captioning, and audio descriptionsto live and prerecorded content for hard-of-hearing web users, and users with learning disabilities?
  • In other words, is time-based media perceivable and understandable?
• Can people with disabilities tab through our website? Can they use screen readers and voice activated devices to access digital content? Did we give them enough time?
  • In other words, are web pages, content, and user interface components operable?
• Do our mobile websites look and behave like they do on a larger screen? Is Zoom enabled for low vision users?
  • In other words, are mobile web pages adaptable (SC 1.3) and distinguishable (SC 1.4)?
• Did we remove a user’s control over her interactions? Are we preventing her from viewing or accessing content as needed when it’s needed?
  • In other words, did we ensure web pages are perceivable and operable?

Embrace diversity

It’s almost impossible to create inclusive user experiences without embracing the diversity of web users and their stories. This blog scratches the surface of designing for disability. To go further, check out Designing Accessible Digital Experiences Begins with Personas and User Stories, and the W3C’s Stories of Web Users; it has extensive guidance on how people with disabilities use the web.

Stay tuned for the final installment of our 4-part series “Evaluating Accessibility in the Product Development Lifecycle” coming soon. Check out Part 1 Plan to be Accessible by Design: Accessibility in the Product Development Lifecycle and Part 2 Define Initial Requirements: Accessibility in the Product Development Lifecycle.

So, What Comes Next?

For those businesses looking to obtain more insights on website accessibility, Perficient has created a set of information to help.

• Download our guide Digitally Accessible Experiences: Why It Matters and How to Create Them.
• There’s more to read on digital accessibility in our UX for Accessible Design series.
• Accessibility IQ identifies and corrects website accessibility issues in weeks, not months.

For more information contact our digital accessibility experts today.

Today 1 in 4 Americans hit virtual roadblocks accessing web content simply because their capabilities, adaptive strategies or their assistive technologies are not considered during the design of digital experiences such as websites.

How many website users in the U.S. could potentially be affected? There are 307 million internet users and 276.8 million mobile internet users in the U.S. accessing the World Wide Web (WWW). The Web has become an indispensable software platform for daily living. For many of these internet users, there’s an unrealized expectation all websites are accessible to everyone to interact with website content, engage with people online, and make life possible when they cannot leave their homes.

We recently learned the Department of Justice (DOJ) wants to ensure website access for persons with disabilities (PWD). And it wants all businesses open to the public to prioritize website accessibility for PWD.

Title III – Businesses Open to the Public

Disability advocacy groups have urged the DOJ to establish regulations to ensure website accessibility for public business entities (e.g., retail stores, banks, hotels, medical facilities, food, and drink establishments and so on). Instead of regulations, the Civil Division of the DOJ gave long-awaited guidance on website accessibility for businesses open to the public under Title III of the ADA (Americans with Disabilities Act, 1990) on March 18, 2022:

“The Department of Justice published guidance today on website accessibility and the Americans with Disabilities Act (ADA). It explains how state and local governments (entities covered by ADA Title II) and businesses open to the public (ADA Title III) can make sure their websites are accessible to people with disabilities in line with the ADA’s requirements.”

Enforcement by the DOJ

This announcement put website accessibility back on the Civil Rights Division’s enforcement agenda to give PWD equal access. And speaking of equal access, the DOJ outlined the responsibility of businesses to avoid discrimination:

“Title III prohibits discrimination against people with disabilities by businesses open to the public also referred to as ‘public accommodations’ under the Americans with Disability Act (ADA). The ADA requires that businesses open to the public provide full and equal enjoyment of their goods, services, facilities, privileges, advantages, or accommodations to people with disabilities.”

Department of Justice Point of View

From the DOJ’s point of view, the ADA was intended to “keep pace with rapidly changing technology of our times.” Starting in 1996, the DOJ held the position that websites should comply with the ADA, even when regulations were not in place.

“The Department of Justice does not have a regulation setting out detailed standards, but the Department’s longstanding interpretation of the general non-discrimination and effective communication provisions apply to web accessibility.”

Kristen Clarke, Assistant Attorney General for the Justice Department’s Civil Rights Division, stated “We heard the calls from the public on the need for more guidance on website accessibility.” The guidance they released seems to accomplish two objectives:

1. It intends to reinforce the DOJ’s current stance with businesses to make public websites accessible.
2. It signals their intention to pursue legal action when accessibility cases are brought to their attention.

The DOJ’s Technical Standards for Website Accessibility

Their website accessibility guidance comprises six categories. Their guidance is written in plain language to make it easy to follow “by people without a legal or technical background.”

To help businesses achieve website accessibility, the DOJ references existing technical standards the Web Content Accessibility Guidelines 2.0 (WCAG). To reinforce a commitment to ensuring websites are accessible, the DOJ shared Title III cases including a settlement with the grocery delivery service Peapod. In this case, Peapod was required to make a series of website adjustments. One, ensuring their website and mobile applications meet WCAG 2.0 AA. Two, asking web users for feedback about their user experience. And three, conducting end-user and automated testing.

Next Steps for Businesses

While it’s clear the DOJ wants businesses to make sure their websites are accessible, it allows “flexibility” in how businesses create them. The flexibility to apply WCAG 2.0 has been challenging in the past. With the DOJ’s recent update, businesses have clearer guidance to “comply with the ADA’s requirements (i.e., nondiscrimination and effective communication).”

So, What Comes Next?

For those businesses looking to obtain more insights on website accessibility, Perficient has created a set of information to help. You can download our guide Digitally Accessible Experiences: Why it Matters and How to Create Them.

Also, there’s more to read on digital accessibility in our UX for Accessible Design series. For more information contact our experience design experts today.

Read Part 1 of this series here: Plan to be Accessible by Design: Accessibility in the Product Development Lifecycle.

Forward-thinking product teams will plan for and implement inclusive user experiences at the start of the design process to achieve better outcomes. More commonly known as Shift Left, this method advocates ‘baking in’ inclusive user experience features in a digital product at the start of product development. Designing for accessibility from the start minimizes refactoring time and associated costs because accessibility issues are identified and corrected before the product reaches the QA (quality assurance) stage.

For teams who didn’t plan for digital accessibility from the start or who rely on manual inspections, automated audit tools, or QA to catch accessibility issues, consider this:

“It is possible to develop an accessible web resource by retrofitting accessibility at the end; however, the effort required can be considerable and the resulting level of accessibility can vary substantially,” says David Sloan in “Case Study: Designing for Web Accessibility”.

Informing product requirements through audience research

To recap from Part 1, a key first step in the product development lifecycle is web user (target audience) research. Getting to know your web users starts with asking a series of questions such as: which user experiences do we want to improve for our target audiences? Which technologies do they use, and how and why are they using them? The User Story of Ali is a snapshot of the nuances of designing for inclusion.

Getting Requirements Off the Ground

With user insights in hand, a product team can start defining initial requirements to satisfy the needs and goals of web users with disabilities. Here are three areas to think about when planning requirements:

Estimating resources
Define team roles and responsibilities. Determine which software will be used to execute the design, development, and testing of the product. Also, decide which browsers and operating systems to design for, which devices to support, and which types of automated tools to use for accessibility evaluations (e.g., developer unit testing to QA tests). Acceptance criteria also need to be decided, as does which type of issue management method to use.

Adopting appropriate accessibility standards and best practices
Web Content Accessibility Guidelines (WCAG 2.1 AA Success Criteria) are globally recognized as the standard to adopt, and they are also best practices. For example, it’s important to include captions and transcripts within live and pre-recorded videos (think of them as text versions of speech) to support users with hearing loss, deafness, and cognitive disabilities, and to offer an alternative such as a PDF of the video content if captions and transcripts are not available. When these best practices are not followed, it creates inaccessible user experiences. In Christina Evans’ article Get Ahead of Headings: How to Correctly Use Headings for Accessibility, she cites a common problem:

“Often times, web developers and designers will use the ‘out of the box’ styling of headings to achieve a specific look of page headings without considering the negative repercussions for accessibility. Using certain <H> tags to style web page titles puts assistive technology users (e.g., blind, and low vision users) at a big disadvantage to visual users as it becomes very difficult to understand web page structure and content. This can lead to assistive technology users becoming so frustrated that they leave your page altogether…to achieve the desired visual look of headings, always style with CSS rather than using HTML <H> tag styling. Doing this will help ensure your site’s information is accessible and inclusive for all users.”

Budgeting for team training
Most teams are comprised of individuals with varying degrees of expertise, so expect teams to routinely upskill. Plan for training by assessing and defining team training needs and goals. Develop a plan to include types of training aligned to team and/or team member goals. Obtain leadership buy-in and routinely monitor and reward or acknowledge success.

So, What Comes Next?

To follow the series, check out Part 1 Plan to be Accessible by Design: Accessibility in the Product Development Lifecycle for more insights.

For further information on how to design for inclusion, contact our experience design experts, check out our Accessibility IQ^SM for your website, download our guide Digitally Accessible Experiences: Why It Matters and How to Create Them, and read more from our UX for Accessible Design series.

Stay tuned for the next installment, Part 3 of 4: Design for Diverse Users: Accessibility in the Product Development Lifecycle.

Accessible Product Development Starts with Shift Left

Using a Shift Left method to improve product development outcomes isn’t new or novel. Shift Left has been adopted for decades to lower software development refactoring time and costs and streamline time to market by testing software earlier in the design process and not just before it ships. “When the software development process is viewed as a left-to-right sequential process, doing testing earlier may be seen as “shifting it to the left.” The term itself can be seen as a misnomer since we are not simply ‘shifting’ but doing tests at all stages of the process,” according to Devopedia.

This methodology has the same benefits for the design of digitally accessible solutions. When implemented, it can deliver better quality code and lower the cost of creating digital experiences for the disability market. Adopting the Shift Left method at the beginning of product development can catch accessibility ‘bugs’ in content creation (e.g. poorly written alternative text for images), within visual and user interaction design (e.g. relying on color alone to convey meaning), and in code (e.g. web pages missing landmarks). Identifying and resolving issues before the quality assurance check is key to reducing refactoring costs.

Today, there’s greater adoption of inclusive design because of the increase in Diversity, Equity, and Inclusion (DE&I) programs by organizations and the recognition that the global disability market consists of 1.85 billion people with $1.9 trillion in annual disposable income.

Accessible by Design

Designing for digital accessibility by implementing Shift Left hinges on a team’s decision to develop for inclusion from the start. More and more, we’re observing organizations committing to digital accessibility. With one of our global OEM clients, our teams work together to ensure web and mobile applications are accessible to meet the needs of its diverse global audiences. Part of the success of our collaboration is our Shift Left approach, which includes things like design reviews by our designer.

Initiating Research

In an earlier blog (Designing Accessible Digital Experiences), I mentioned that you need to set aside assumptions about the ideal web user who never encounters issues accessing online information. The same applies to creating inclusive and usable experiences for persons with disabilities (PWD). Start by setting aside assumptions about PWD and begin by asking questions such as: who is my user? Which of our client’s target audiences would benefit from inclusive design choices? What is the user experience we want to improve? Which technologies are they using, and how and why are they using them?

There are multiple user research methods to understand target audiences and get those answers. User interviews, surveys, diary studies, observation, and combing through clients’ chat logs and research data are all great ways to surface meaningful insights.

It’s common for design teams to rely on the Web Content Accessibility Guidelines (WCAG) and its 50 Success Criteria to checklist their way to compliance. Product development teams may use a subject matter expert (SME) to steer the accessible design process. These approaches can improve the accessibility of a web experience, but they do not ensure usability (i.e. effective, efficient, engaging, easy to learn, and error-proof – W. Quesenbery).

The User Story of Ali

Let’s examine a sample user, Ali. If we interviewed Ali and observed how she uses her mobile device, we would learn more than making initial assumptions about her capabilities, needs, and pain points or using the WCAG checklists. It’s not apparent she has low vision or that she has created an adaptive strategy for herself with the help of VoiceOver (Apple’s built-in screen reader) to add events to her calendar. And by the way, her right wrist is injured from a strenuous workout, so tapping or swiping is a challenge. This temporary disability should be considered in designing an accessible experience. Not everyone has fine motor skills.

Another key decision when designing for disability is thinking about people’s different interaction styles and settings (e.g., voice, braille, zoom, tap, scroll, dark mode, etc.), the various devices they use, their input methods, and their preferred operating systems and browsers.

User research enhances every web experience, but excluding persons with disabilities makes all research methods meaningless. Start the product development lifecycle with Shift Left. And remember, every team member has a part to play in research, even if it’s observing PWDs using a prototype or website in production and offering insights on improving the overall user experience or fixing a specific issue.

So, What Comes Next?

Adding accessibility in the product development lifecycle with upfront user research is the first step your teams must take to help ensure your digital experiences are inclusive and accessible by design.

For further information on how to make your design understandable to your audience, contact our experience design experts, check out our Accessibility IQ for your website, download our guide Digitally Accessible Experiences: Why It Matters and How to Create Them, read more from our UX for Accessible Design series, and stay tuned for the next installment: Setting Product Requirements: Accessibility in the Product Development Lifecycle Part 2 of 4.

The disability market has hit an inflection point. More global organizations buying tech are committing to accessibility in 2022 due to pressure created by the increasing number of digital accessibility lawsuits, and the increasing number of firms creating diversity and inclusion programs (DE&I). This is creating competition for opportunities to attract the global disability market of 1.85 billion people with accessible and satisfying user experiences (UX) for consumers, internal talent, and partners. Attracting this target audience requires understanding their diverse stories and disabilities, particularly when 70% are invisible disabilities.

Context, Technologies, and User Goals

The opportunities to design for accessibility must consider how your target audience will use your application or website, and with what technologies, languages, and locations. Are they at their home office using a large monitor to analyze a spreadsheet? Are they taking a walk while reviewing a video on their phone? Or are they ordering groceries from their notebook at the airport? Most importantly, what are their abilities? Knowledge of your target audience based on these factors minimizes badly designed experiences that exclude people from using the web.

User Diversity Stories

Forget assumptions about the ideal user who never encounters issues accessing online information. All web users hit roadblocks with websites, videos, and other interactive media at different times. Although from an accessibility point of view, removing roadblocks is critical, and doing that is largely about making informed product design choices by first considering people’s diverse user stories and their challenges accessing web content.

Some examples of these user stories and challenges are the following:

• Situational challenges: Confusing industry jargon or complex sentences
• Temporary impairments: An accident limits the ability to navigate a mobile device
• Health conditions: Pain, fatigue, memory loss, or others can impact the duration of web use
• Changing abilities: Some accessibility features are needed one day, but not another day
• Multiple disabilities: Disability comes in combinations such as deaf and low vision
• Age-related impairments: Different assistive technologies could be needed for younger users with the same issue as older users

Now let’s Look at 4 Primary Personas

These four disability types include many website users. When we design for their goals, abilities, and technologies, we can eliminate barriers that exclude them from using the web, which also creates higher-quality web pages.

About Leo

“Why is this so tricky?”

Leo needs accessible alternatives to a mouse because he struggles with fine motor control. He likes large click targets and more time to complete a task. Leo might use the speech-to-text app, Dragon Naturally Speaking, because it’s hard to tap on buttons and links.

Leo is helped by the W3C “Operable” Principle – the user interface (UI) components and navigation are ideally programmed to work independently of the device that he is using. In other words, the UI cannot require interaction that Leo cannot perform.

How people like Leo use the web:

• Diverse abilities and barriers
• Stories of web users – Alex and Yun
• Examples of physical disabilities

About Tyra

 “Often I’m confused by unfamiliar words, expressions and lack of context.”

Like many people with hearing loss, Tyra needs information shown in formats she can understand and written for a non-native English speaker. She likes transcripts and captions in multiple languages. She might even use a translation app.

Tyra is helped by the W3C “Understandable” Principle – any web user can easily understand information without asking for help and how to interact with information on whichever device is being used at that moment.

How people like Tyra use the web:

• Diverse Abilities and Barriers
• Stories of web users – Martine and Kaseem
• Examples of auditory disabilities

About Ava

“It really bugs me when CSS is used to convey the meaning of a web page.”

Many people like web designer Ava grasp information more easily when it’s logically laid out on a web page from the header down to the footer using landmarks. This is helpful to people with low vision and color contrast deficiencies, or for blind web users and their technologies such as VoiceOver, Talkback and NVDA.

Ava is helped by the W3C “Perceivable” Principle – information needs to be presented in more than one format. In other words, a perceivable design simply means that people using assistive technology (or not) can know it’s there.

How people like Ava use the web:

• Diverse Abilities and Barriers
• Stories of web users – Lee, Ilya, and Yun
• Examples of visual disabilities

About Mick

“I stay current with technology, although it’s a challenge.”

People of any age, and more commonly older web users, may have difficulty processing information such as numbers or words, difficulty with complex concepts, short attention spans, and memory impairment. In other words, some web users have cognitive and/or psychological disabilities. These web users need more time to read and use content, and they might use text-to-speech software such as a VoiceOver software to hear directions and pop-up blockers to minimize distractions.

Mick is helped by the W3C “Understandable” Principle – information and UI components help users such as identifying the primary language of the page, providing definitions for idioms and abbreviations, and using plain language and simple layouts as much as possible.

How people like Mick use the web:

• Diverse Abilities and Barriers
• Stories of web users – Preety, Yun, and Luis
• Examples of cognitive disabilities

The Vision for Digital Accessibility

The World Wide Web founder Tim Berners-Lee always envisioned the web to be accessible to everyone, navigate and interact with website content, engage with other people online, and in some cases, make life possible if you cannot leave your home. Check out the W3C’s Web Accessibility Perspectives video for insights on making your digital experiences accessible based on the diverse stories of web users. You can find the individual videos on the W3C site.

For more information on web accessibility, download our guide, Digitally Accessible Experiences: Why it Matters and How to Create Them, and contact our experience design experts today.

In my post from August, we learned how to effectively include stop, pause, hide, or volume changing controls into your video content to ensure the content is accessible to all users. Now we’ll learn a little more about the value of including captions for both pre-recorded and live videos, as well as the option to download a transcript of a video’s audio.

Below you’ll see an example of a live video with generated captions that synchronize with the video as the man continues to speak. Generated captions are also available to pre-recorded content. To the right of it, you’ll also find his speech that will be downloadable as a transcript for the user to review later with the “download transcript” button at the bottom.

The addition of captions and the button to download transcripts for later usage make your video content more accessible to audiences who are hard of hearing and deaf, and it helps people with cognitive and learning disabilities who may struggle to retain audio (spoken) content. It’s also useful to have transcripts to refer to later if you are writing a report or conducting research. Captions and transcripts make it easy for everyone to interpret information accurately and in the case of real-time captions.

These functionalities are easy to incorporate. For more information on creating accessible web and digital experiences, download our guide, Digitally Accessible Experiences: Why It Matters and How to Create Them, and to start on your accessibility journey, contact our experience design experts about our Accessibility IQ today. And, to learn more about accessible videos, check out Web Content Accessibility Guidelines 1.1.1 (Non-text content), 1.2.1 (Pre-recorded Audio-only and Video-only), and 1.2.2( Captions).

We’ve been looking at The Web Content Accessibility Guidelines (WCAG) 2.2 Guidelines for several weeks, and we’re now rounding out this series by taking a close look at 5 of 9 WCAG 2.2 A, AA, and AAA Success Criteria. If you haven’t been following this series, the W3C released a working draft of WCAG 2.2 by the Accessibility Guidelines Working Group, and while it hasn’t been fully adopted, it’s expected to become an official recommendation by the end of 2021.

The 2.2 Guidelines and Success Criteria build upon earlier versions of WCAG 2.0 and 2.1, which were created from the first version (WCAG 1.0) released in 1999. Today, WCAG 2.2 introduces additional use-cases and its working draft will likely include these 9 new success criteria to improve support for:

• Users of small or touch-screen devices
• Low-vision users
• Users with cognitive, language, and learning disabilities

In “A New Standard for Interacting with the Web by Keyboard or Screen Reader,” we covered two success criteria, “Focus Appearance,” both Level AA “minimum” and Level AAA “enhanced.” In our most recent article from September, “A New Standard for Interacting with the Web: Beyond the Keyboard and Screen Reader,”  we took a dive into another 2 of the 9 success criteria, Dragging Movements (Level AA) and Target Size (Minimum) (Level AA).

A Close Look at 5 of the 9 Success Criteria

Page Break Navigation: Success Criterion 2.4.13 Level A

Users of assistive technology, such as a screen reader, need to find references to content based on page break locators, which are “destination markers” which guide users through meaningful points within content. Here’s an example from the W3C: “A digital book is published with no print equivalent and page break locators are inserted, which supports direct navigation across platforms and form factors.” This criterion benefits low-vision users, helping them know how to move from one page to another page in a text.

Consistent Help: Success Criterion 3.2.6, Level A

Every online user needs help completing tasks, but at times it’s hard to find. To create an effective user experience accessing help should be provided on the page or potentially as a direct link to another webpage with helpful information. Also, help should take additional forms such as human contact details like phone numbers and hours of operation, a FAQ page, user guide, contact form, and a fully automated chatbot. Chatbot technology has evolved, but people with cognitive disabilities can struggle to use them, so, these chatbots should:

• Recognize misspelled words
• Provide human contact details if the chatbot is unable to provide a satisfactory response after 3 attempts
• Be dismissed with a single interaction and recalled using a link or button.

Keep in mind, this success criterion requires that whatever type of help we provide, it should be shown or provided in a consistent location, and in more than one format.

Visible Controls: Success Criterion 3.2.7, Level AA

There are people online every day who have cognitive and learning disabilities, memory impairments, low vision, and mobility impairment, and they struggle to use websites and other interactive media because user interface (UI) elements (aka, controls) are hidden until discovered – in some cases by accident. There are many user stories in which this is a problem, here are two:

• Low vision users cannot find UI elements at all if they’re revealed only on hover.
• Memory impaired users cannot recall where an element was located.

Keep these guidelines handy, from the W3C:

“Information needed to identify controls must be visible when the controls are needed without hover interaction or keyboard focus. Controls can be available through a persistent visible entry point, such as a menu button that opens subitems. In a multi-step process or multi-part form, controls may be hidden in an earlier step or part; however, at the time the user can move the process forward, the information needed to identify the control, which is usually the control itself, must be visible without hover interaction or keyboard focus.”

Accessible Authentication: Success Criterion 3.3.7, Level A

All web users encounter cognitive function tests with little thought. Every day we’re asked to enter our username and password to access various accounts. The reality is very few web users can remember their username and password combinations without prompts or saving them. Those web users with cognitive and memory disabilities are at a greater disadvantage. “Memorizing a username and password (or transcribing it manually) places a very high or impossible burden upon people with certain cognitive disabilities,” according to the W3C. In a nutshell, cognitive function tests will exclude some people unless an additional method of authenticating is available.

Lately, we’re seeing a positive trend, websites are optionally allowing users to see their passwords as they’re typing it in. Who does this benefit? Many people! We highly recommend checking out the authentication examples from the W3C’s 3.3.7 Success Criteria.

Redundant Entry Success Criterion Level 3.3.8, Level A

Almost 30 years ago, Jakob Nielsen released a set of usability heuristics, and number 6 on the list of 10 best practices was “minimizing the user’s memory load…users should not have to remember information from one part of the interface to another.” That’s more than useful for people with cognitive or memory difficulties, and it helps ensure they complete tasks efficiently instead of giving up due to fatigue or frustration.

The “Redundant Entry” Success Criterion is similar. It removes the burden of recalling information when it’s asked for more than once or was given in a prior step. A classic example of removing redundant entry is the ecommerce checkout entry fields for delivery and billing addresses. When they are the same users can skip entry redundant information.

If previously provided information is required again, the better design is to auto-populate it or make the information available for a web user to select. There are exceptions though:

• If re-entering this info is essential
• Information is required (security reasons)
• Previously entered information is no longer valid

That’s All for the WCAG 2.2 Accessibility Series, Folks!

To learn more about creating an accessible design strategy for your business, download our guide, Digitally Accessible Experiences: Why It Matters and How to Create Them, and read our UX for Accessible Design series and UpSkill series. To get started on enhancing your digital accessibility, contact our experts about our Accessibility IQ today.

Every person using the web has different abilities when it comes to reading and interacting with online content. Naturally, they have varied needs as well. In this article, we’ll carry forward the theme we started in part one and part two of this series – the importance of a keyboard or screen reader (robust forms of technology) that make information like forms, videos, images, content, menus, and links accessible to people with different abilities. We’ll introduce proposed 2.2 Guidelines from the Web Content Accessibility Guidelines (WCAG) that go beyond both keyboard and screen reader interactions.  

The Current Situation with Users and Access 

People are always changing or upgrading their devices, software, and browser versions so technology solutions must adapt and keep up, especially for the 1 billion global users who have a disability (visual, hearing, mobility, cognitive, and learning). To meet that need, the WCAG 2.2 has been drafted to continue to create more inclusive user experiences. 

The W3C recently released their working draft of WCAG 2.2 by the Accessibility Guidelines Working Group and those guidelines and success criteria build upon earlier versions of WCAG 2.1 and 2.0, which are built from the first version (WCAG 1.0) released in 1999. Now today, WCAG 2.2 introduces additional use-cases. Notably, it includes improvement in support for users of small or touch-screen devices, low-vison users, and users with cognitive, language, and learning impairments. We’ll take a closer look at two Guidelines: “Input Modalities and Dragging Movements” and “Target Size.” 

Guideline 2.5.7 Input Modalities/Dragging Movements 

The WCAG Guideline “Input Modalities” is specifically focused on “dragging movements” and “target size” (think buttons). Both forms of interaction have a notable impact on users with motor skill impairment. 

Dragging movements have become common user interactions for mobile and tablet devices, this presents a challenge to a lot of users. This guideline intends to “make it easier for users to operate functionality through various inputs beyond keyboard” according to the W3C organization, such as using a “single pointer.” However, there is an exception when a dragging movement is “essential.” For example, if a dragging movement is removed and it “fundamentally changes the information or functionality of the content, such as drawing a freeform figure, it should stay as an interaction. The key idea for designers is to implement an inclusive design for dragging functionality such as the up or down buttons or clicking controls.   

The Use Story of “Yun” 

To illustrate, take a typical user story of Yun an 85-year-old retiree that reads news online, and posts to social media sites to stay connected with his kids and grandkids. Yun has hand tremors, as do many people his age, and it’s impossible for him to hold down the mouse button and drag accurately to “move the items in this list.” To design a better experience for Yun’s abilities and those like him, design clickable up and down arrows to change the order of items in the list. It’s a solid solution that will work for more people too, not just Yun, coined as solve for one benefit many. 

To get a full understanding of how to design and develop dragging movements to work for most people, check out the W3C’s guidance on intent, benefits, examples, techniques, and key terms.  

Guideline 2.5.8 “Target Size”  

The WCAG Guideline “Target Size” resolves problems with clicking or tapping on user interface (UI) components (such as a button) which are designed with insufficient “region.” It also helps prevent accidentally activating a nearby target because it is too small and too close to its neighboring target. The W3C outlines “an area of at least 24 by 24 Cascading Style Sheet (CSS) pixels” for the size of the target. Depending on the design of the UI components on a page, you may need to enlarge the size of certain targets or increase “padding” around the target. There are three exceptions to this guideline. 

• Spacing: The target offset is at least 24 CSS pixels to every adjacent target. 
• Inline: The target is in a sentence or block of text. 

• Essential: A particular presentation of the target is essential to the information being conveyed, or it is legally required to be presented. 

Having a sufficient region of 24 by 24 CSS pixels solves common user experience (UX) frustrations for people with low vision, and especially for people with large finger pads and those with different motor skill abilities. Take Yun for instance. He is shopping online for groceries, during checkout he realizes he needs another item. Instead of hitting “Back,” he accidentally hits “Submit” simply because the buttons are too close together. Taking this into consideration is especially important when designing for various mobile screen sizes.  

This illustration from the W3C makes clear the options to pass this guideline. Another key design choice to note about target size relates to zooming. Target size is “independent of the zoom factor on the page; when users zoom in the CSS pixel size (of elements) does not change.” Another design consideration – if there are no targets immediately above or below the buttons, the region passes the Success Criterion.  

What We Will Learn Next 

Coming next is WCAG 2.2 Guidelines “Predictable” and “Input Assistance.”  Until then, to learn more about creating an accessible design strategy for your business, download our guide, Digitally Accessible Experiences: Why It Matters and How to Create Them, and read our UX for Accessible Design series and UpSkill series. To get started on enhancing your digital accessibility, contact our experts about our Accessibility IQ today.