Skip to content

Category: WCAG

Published 2023/11/30

Artificial Intelligence & Accessibility

Since November 2023, Microsoft Disability Answer Desk callers who are blind or low vision can now use Be My AI™ to handle all types of customer service calls. Everything from Excel spreadsheet formulas to interpreting product instructions and diagrams, rebooting a laptop or installing and updating software, and much more.

Four smartphone screens are displayed to demonstrate the user experience walk-through of connecting with Be My AI™ via Microsoft’s Specialized Help profile in the Be My Eyes app. The first smartphone screen on the far left shows the Microsoft company profile in Be My Eyes. The second smartphone screen shows the screen that appears when a blind user selects “Chat with Be My AI.” Be My AI™ sends a message to the users that reads, “Hello! This is Be My AI™ from Microsoft. How can I assist you today?” The third screen shows the conversation with Be My AI™ continued, where a user asks, “How do I disable Microsoft Outlook?” The fourth and final smartphone screen shows the smartphone camera pointing its rear-facing camera onto a Microsoft Outlook inbox on a computer desktop screen.

This is the first use of AI accepting image inputs to augment traditional customer service for people with disabilities. The global deployment meets what Be My Eyes refers to as the 3S Success Criteria™:

  • Success: a 90% successful resolution rate by Be My AI™ for Microsoft customers who try it. Put another way: only 10% of consumers using AI interactions are choosing to escalate to a human call center agent.
  • Speed: Be My AI™ solves customer issues in one-third the time on average compared to Be My Eyes calls answered by a live Microsoft agent (4 minutes on average for Be My AI vs. 12 minutes on average for live agent support).
  • Satisfaction: customer satisfaction ratings have improved with the implementation of Be My Eyes in Microsoft’s Disability Answer Desk with interactions averaging 4.85 out of five stars.

Github Copilot

In other AI Accessibility news, I’ve been reading about Github Copilot. I’m generally in favor of automation, to a degree. In the early days of the web, I was an old school HTML coder. Back when we still built page layouts using table tags (it was pretty terrible but we didn’t know better yet). I remember when the first WYSIWYG editors started coming out in the 90s. The first time I saw Dreamweaver I was simultaneously stoked and horrified. Sure, it made it easier for anyone to build out web pages. Unfortunately, it also generated so much unnecessary, nested, bloated HTML.

Fast forward to today. GitHub describe their Copilot service as an “AI pair programmer.” Examples on their website show it writing whole functions from a comment or a name. Unfortunately, many of Copilot’s suggestions include serious accessibility bugs. Developer Matthew Hallonbacka posted about his findings as they relate to:

  • Alt Attributes
  • Identifiable Links
  • Focus States
  • Spans that should be buttons
  • Color contrast ratios

The danger is that developers will accept code suggestions, assuming they are valid. Be cautious when using Copilot. If you’re expecting a certain type of suggestion but receive one with extra attributes, take the time to look up those attributes. Don’t use the code until you understand what every part of it does.

Leave a Comment
Published 2023/10/15

Getting to Know WCAG 2.2

First, what is WCAG:

The Web Content Accessibility Guidelines (WCAG) are part of a series of web accessibility guidelines published by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C), the main international standards organization for the Internet. They are a set of recommendations for making Web content more accessible, primarily for people with disabilities—but also for all user agents, including highly limited devices, such as mobile phones.

Wikipedia

WCAG Version 1.0 was published in May of 1999. I’d already been a front end web developer for several years at that point. I recall thinking these guidelines were a great idea. Even early on, I understood the inequity of the web and barriers to access. At that time, it was still somewhat rare to have access to the internet at all, via dialup or DSL. But those who did have internet access ran into barriers created by inaccessible Flash files, for example.

As web technologies evolved, the guidelines were updated. WCAG 2.0 was published in December 2008. Nearly a decade later, WCAG 2.1 was published in June of 2018. And, as of October 5th, the WCAG 2.2, is finally official! For those following this closely, it’s felt like a game of Chutes and Ladders. WCAG 2.2 went up the ladder to reach the Candidate Recommendation (CR) phase more than once in the last couple of years. Only to be knocked back down the slide to be reworked.

Initially, Focus Visible was going to bump up from Level AA to Level A in WCAG 2.2. I was thrilled about this. When there are multiple elements on a webpage, visible focus helps highlight which element has the keyboard focus. This helps users who rely on a keyboard to navigate. It shows them which element the keyboard will interact with. Users with attention or short-term memory limitations also benefit from a visual cue to where focus is located. Unfortunately, it’s remaining at Level AA. I’m not the only one disappointed by this. Despite that, other gains have been made.

Level A

  • 3.2.6 Consistent Help: Certain help mechanisms that are repeated on multiple web pages must occur in the same relative order to other page content, unless a change is initiated by the user.
  • 3.3.7 Redundant Entry: Information previously entered by or provided to the user that is required to be entered again in the same process must be: auto-populated or available for the user to select.

Level AA

  • 2.4.11 Focus Not Obscured: When a user interface component receives keyboard focus, the component must not be entirely hidden due to author-created content.
  • 2.5.7 Dragging Movements: All functionality that uses a dragging movement for operation must be achievable by a single pointer without dragging. Unless dragging is essential or the functionality is determined by the user agent and not modified by the author.
  • 2.5.8 Target Size: The size of the target for pointer inputs must be at least 24 by 24 CSS pixels (with some allowable exceptions).
  • 3.3.8 Accessible Authentication: A cognitive function test must not be required for any step in an authentication process, unless specified criteria are met.

Level AAA

  • 2.4.12 Focus Not Obscured (Enhanced): When a user interface component receives keyboard focus, the focus indicator SHOULD NOT be hidden at all (even partially) by author-created content.
  • 2.4.13 Focus Appearance: When the keyboard focus indicator is visible, an area of the focus indicator should meet specified size and color contrast requirements.
  • 3.3.9 Accessible Authentication (Enhanced): A cognitive function test should not be required for any step in an authentication process, unless there is an alternative method without a required cognitive test or there is a mechanism to assist the user.

Lastly, the obsolete 4.1.1 Parsing has been removed altogether.

The folks at Intopia have already published an updated WCAG 2.2 Map. The map provides an overview of WCAG in a visual format, breaking down success criteria by level of conformance. Their accompanying article is helpful as well.

The WCAG 2.2 Map featuring all success criteria laid out around four quadrants for Perceivable, Operable, Understandable, and Robust.
Leave a Comment
Published 2023/04/24

Spring Cleaning for Accessible Content

It is springtime in Minnesota. Which means we reached a high of 88° one April afternoon, then it snowed just days later. Despite the wildly fluctuating weather, I feel the urge to purge. I’ve tossed piles of junk mail in the recycling bin. Winter sweaters will be moved to storage (soon, I hope). Other items will be given away via our local Buy Nothing group. I may not go the full Marie Kondo method with my tidying, but controlling clutter in my physical space makes me feel better, mentally. You know what else sparks joy for me? Accessible content!

Self-portrait holding a lit sparkler in the darkness with the light illuminating my face

Recently, WebAIM released their annual report on the most popular 1,000,000 home pages on the web. 96.3% of them detected WCAG 2 failures. And that’s just what automated testing found. Manual testing would likely reveal many more.

Across the one million home pages, 49,991,225 distinct accessibility errors were detected—an average of 50.0 errors per page. 

The WebAIM Million

Many of those pages may not be relevant anymore and could be retired. Or portions of their content are likely out of date. Clean it up! Disability and accessibility expert Sheri Byrne-Haber has a great post about this:

Sometimes the best way to make something #accessible is to get rid of it.

I wrote an article about this a while back – the very first thing accessibility leaders should think about when tackling remediation is “do we need this at all?”

– Do we need this graphic / table?
– Do we need this CAPTCHA?
– Do we need this 17 year old inaccessible report that no one ever opens
– Do we need a press release on the election of someone to the board that is no longer on the board?

Don’t pack all your content indiscriminately and move it over to the new accessible template. Go through a cleanup first, and just bring the valuable content over that your users still need.

Sheri Byrne-Haber on LinkedIn

There’s more on her website. Her blog post Starting a new accessibility remediation project? outlines helpful “approaches and prioritization that will make your end goal of an accessible website easier and cheaper.” As someone who has been involved in many, many content migration projects, I fully back this approach. The most successful ones only ported what was still purposeful. Content that has been removed doesn’t need to be remediated. Unnecessary content is a distraction. Inaccessible content can be a blocker. Slimming websites down to the essentials will reduce cognitive load, making them more usable for everyone. Ditch that carousel no one clicks through. Get rid of that busy graphic. Embrace the joys of minimalism.

Leave a Comment
Published 2023/01/26

WCAG 2.2 Deja Vu

It feels like deja vu, but WCAG 2.2 has reached the Candidate Recommendation (CR) stage, again. After it reached the CR stage in September 2022, enough feedback was provided to drive these changes. One of them, in particular, makes me happy. The obsolete 4.1.1 Parsing has been removed. Parsing issues no longer cause accessibility blockers thanks to how much browsers and assistive tech have improved. When performing accessibility testing, it has often been difficult to justify failing this success criterion. Focus Visible is bumping up from AA to A, which is the other great news I’ve been aware of for a while. Now we’ve just got to keep waiting it out until WCAG 2.2 is final.

While we wait for that, there’s plenty to keep us occupied in our community:

March

  • International Wheelchair Day celebrated annually on March 1st
  • CSUN Assistive Technology Conference: From March 13-17, 2023 an inclusive setting for researchers, practitioners, exhibitors, end users, speakers and other participants to share knowledge and best practices in the field of assistive technology.
  • axe-con 2023: Hosted on March 15-16, 2023, axe-con is completely free and virtual. Axe-con is an open and inclusive digital accessibility conference that welcomes developers, designers, business users, and accessibility professionals of all experience levels to a new kind of accessibility conference focused on building, testing, and maintaining accessible digital experiences.

April

May

W3C Web Accessibility Initiative WAI, WCAG 2 Web Content Accessibility Guidelines text with icons for touch, vision, cognitive, hearing, speaking, and general accessibility
1 Comment