Day 70: How to Fail WCAG Level AA, Part 1

The last three days I’ve reviewed failures for WCAG Level A within Perceivable, Operable, and Understandable and Robust. Now it’s time to step up our expectations and look out how we’re all fairing at the middle conformance level: Level AA.

Things I accomplished

  • Read through Perceivable success criteria (Level AA) techniques on How to Meet WCAG 2 site.
  • Mapped success criteria to failures.

What I learned today

Within the Perceivable principle, there are 11 additional success criteria to meet Level AA conformance within the latest WCAG recommendation (2.1).

5 SC within WCAG 2.0:

  • 1.2.4 Captions (live)
  • 1.2.5 Audio descriptions (pre-recorded)
  • 1.4.3 Contrast (minimum)
  • 1.4.4 Resize text
  • 1.4.5 Images of text

6 more SC added in WCAG 2.1:

  • 1.3.4 Orientation (new to 2.1)
  • 1.3.5 Identify input purposes (new to 2.1)
  • 1.4.10 Reflow (new to 2.1)
  • 1.4.11 Non-text contrast (new to 2.1)
  • 1.4.12 Text spacing (new to 2.1)
  • 1.4.13 Content on hover or focus (new to 2.1)

Examples that fail base conformance

SC 1.2.4 Captions (live):  In Level A, pre-recorded video with audio required captions. Level AA conformance fails when no open/closed or synchronized text stream is provided with captioning during live synchronized video with audio. This affects people with hearing impairments.

SC 1.2.5 Audio descriptions (pre-recorded): In Level A some sort of alternative (AD or text) needs to be provided for videos. Level AA conformance fails when there is no audio description track provided. This presents a challenge to users who may not be able to see the video.

SC 1.3.4 Orientation (new to 2.1): The user is prevented from using landscape view within a web app that does not essentially need to remain in portrait view. This affects people who magnify the screen and choose to view webpages in landscape.

SC 1.3.5 Identify input purposes (new to 2.1): No input data type or instructions for restricted data input are conveyed to the user. This affects people who use screen readers and some people with cognitive disabilities.

SC 1.4.3 Contrast (minimum): Background color and foreground text color have a contrast ratio of under 4:5:1 which makes it hard for people with visual impairments to perceive.

SC 1.4.4 Resize text: When text is resized within the browser at 200%, text is clipped. This makes reading your text difficult for people with visual impairments.

SC 1.4.5 Images of text: An image with text was used, even though it could have been presented in the same way with true text and use of CSS. This greatly affects people who magnify or zoom into their screen and the image pixelates.

SC 1.4.10 Reflow (new to 2.1): Media queries are absent. Content forces user to scroll horizontally and vertically. This presents a challenge to people who need to enlarge text or zoom into the screen.

SC 1.4.11 Non-text contrast (new to 2.1): Low contrast between text box and its background. No border is present. Like SC 1.4.3, this affects anyone with a visual impairment, including colorblindness.

SC 1.4.12 Text spacing (new to 2.1): Content boxes are restrictive in size and don’t allow for text spacing to be adjusted by the user without text being clipped. This greatly affects people with visual impairments, dyslexia, and cognitive disabilities.

SC 1.4.13 Content on hover or focus (new to 2.1): Custom tooltip is not persistent nor dismissable. This greatly affects people who magnify their screen.

In conclusion

I had to cut the list of Level AA SC in half since there are 20 additional criteria, in total. I’m feeling a little more confident about my organizations efforts to achieve Level AA, and am happy to see that other people are paying attention to color contrast and reflow issues. Pertaining to the Perceivable principle, I don’t think it takes to much effort to step up a level to remove even more barriers for people of all abilities.

Day 69: How to Fail the Bare Minimum of Understandable and Robust

Today I’m concluding Level A conformance evaluation, looking at the Understandable and Robust principles of WCAG.

Things I accomplished

  • Read Understandable and Robust success criteria (Level A) failure techniques on How to Meet WCAG 2 site.
  • Mapped success criteria to failures of those criteria that I’ve encountered or read about.

What I learned today

There are 5 bare minimum (Level A) success criteria recommended by W3C in order for websites to be understandable (readable, predictable). These success criteria are, as follows:

  • 3.1.1 Language of Page
  • 3.2.1 On focus
  • 3.2.2 On input
  • 3.3.1 Error identification
  • 3.3.2 Labels or instructions

There are 2 bare minimum (Level A) success criteria recommended by W3C in order for websites to be robust (compatible for assistive tech and adaptive strategies). These success criteria are, as follows:

  • 4.1.1 Parsing
  • 4.1.2 Name, role, value

When these seven success criteria are met, it enables people of different abilities, no matter what aids they use, to understand and continue using your online content and services.

Examples that fail base conformance

SC 3.1.1 Fail:  A lang attribute is not present on the html element. The language of the web document needs to be explicitly defined for screen readers and browsers.

SC 3.2.1 Fail: Link opens a new tab. This should be avoided if not critical for the user because it can be disorienting to people of all abilities. I still see this a LOT for links, in particular, where no alternative of additional warning text is provided.

SC 3.2.2 Fail:  Form submitted ‘onchange’ rather than allowing the user to submit the form when they were actually done. This impairs people from completing forms accurately and at their own pace.

SC 3.3.1 Fail: No descriptive error text was provided for required fields to help user know why their form was unable to submit.

SC 3.3.2 Fail: No label was associated with an input control by using ‘for’ and ‘id’.

SC 4.1.1 Fail: I’ve recently run across a few of these failures! They usually come down to typos. For instance, if quotes or brackets aren’t closed, or no space is left between attributes, it can create an incomplete picture for assistive technologies and browsers.

SC 4.1.2 Fail: No role, name, or state were provided on a custom component control with a div or span.

In conclusion

Though this evaluation was shorter, I recognized several things I knew to cause accessibility problems, but I didn’t realize how bare minimum they were in this specification and how long they’ve been around (none are new in 2.1). I would be bold enough to say that all of these are easy failures to avoid and come at no real cost to the developer who knows what she’s doing. Now, if you’ll excuse me, I have a few bare minimum things to fix in my code this week…

Tomorrow I’ll start looking at the next level up, which is a common goal for many organizations, including my own. I’ll find out if we’re meeting that goal or not!

Day 68: How to Fail the Bare Minimum of WCAG Operable

Yesterday I got a head start on looking through the Level A conformance fails within WCAG’s perceivable principle. To keep that momentum going, I’ll be traversing through the other “bare minimum” recommendations to make sites mostly accessible with minor challenges. Today my sights were set on Operable.

Things I accomplished

  • Read Operable success criteria (Level A) failure techniques on How to Meet WCAG 2 site.
  • Mapped success criteria to failures of those criteria that I’ve encountered or read about.

What I learned today

There are 14 bare minimum (Level A) success criteria recommended by W3C in order for websites to be operable (keyboard, mouse, touch, voice, switch). That’s almost half of Operable’s success criteria! These success criteria are, as follows:

  • 2.1.1 Keyboard
  • 2.1.2 No keyboard trap
  • 2.1.4 Character key shortcuts (new in WCAG 2.1)
  • 2.2.1 Timing adjustable
  • 2.2.2 Pause, stop, hide
  • 2.3.1 Three flashes or below threshold
  • 2.4.1 Bypass blocks
  • 2.4.2 Page titled
  • 2.4.3 Focus order
  • 2.4.4 Link purpose (in context)
  • 2.5.1 Pointer gestures (new in WCAG 2.1)
  • 2.5.2 Pointer cancellation (new in WCAG 2.1)
  • 2.5.3 Label in name (new in WCAG 2.1)
  • 2.5.4 Motion actuation (new in WCAG 2.1)

When these fourteen operable success criteria are met, it enables people who use assistive technology and adaptive strategies to access, navigate, and interact with your static and dynamic content.

Examples that fail base conformance

SC 2.1.1 Fail: Several projects I’ve worked on have implemented hover-only focus styling effects or tooltips/pop-ups that excluded keyboard users.

SC 2.1.2 Fail: Modals can be tricky to create. When the keyboard user has no way to close the modal (Esc or Tab to close button) and get back to the content, this SC doesn’t pass.

SC 2.1.4 Fail: Creating single-character keyboard shortcuts without giving the user control to deactivate or change those shortcuts can greatly affect keyboard and speech input users.

SC 2.2.1 Fail: I am guilty of the client-side meta redirect! I know now that setting a timer of any kind requires extra consideration for people who need more time to make decisions and understand what’s going on. There is no user control in this situation.

SC 2.2.2 Fail: Carousels, the bane of my existence, can easily fail this success criteria if it doesn’t have a pause, stop, or hide mechanism. It’s taking choice away from any user. Additionally, it makes content less perceivable by people with visual or cognitive disabilities.

SC 2.3.1 Fail: I’ve seen video ads, fixed a web page, that are not only distracting, but have a flashing when its trying to grab a users attention. If the contrast is high and lasts more then 3 flashes, it’s a fail. Not only does it fragment attention for people with cognitive disabilities, but could create a severe reaction for people with photosensitive seizure disorders.

SC 2.4.1 Fail: No additional links are provided to skip repetitive content or navigate to different regions of the page. This creates an exhaustive experience for keyboard users tabbing through that web page.

SC 2.4.2 Fail: This is a current issue I’m battling. A web page doesn’t have a unique title or descriptive title that identifies the pages purpose or intent.

SC 2.4.3 Fail: I’ve seen some bad tabindexing, which ruins the relationship between keyboard (or screen reader) navigation and understanding content’s logic.

SC 2.4.4 Fail: This is a recent fail I’ve found in a recent accessibility audit. An image is linked, but there is not alternative text given to that image to let a screen reader user know what it’s purpose is.

SC 2.5.1 Fail: Custom complex gestures (requires multiple touch points) for touch devices is difficult for people with motor disabilities and those who use assistive technology that cannot equate these actions.

SC 2.5.2 Fail: No room for touch error was enabled. People with visual, cognitive, and motor disabilities could suffer from accidental button activation or disorientation when inadvertently taken to another part of the site.

SC 2.5.3 Fail: Visible linked text is different from a hidden accessible name (i.e. title or aria-label), which becomes an unknown hidden voice command for people who use speech input to operate controls and navigate the webpage. It also confuses understanding of content for screen reader users.

SC 2.5.4 Fail: No alternative means of control activation other than device motion (e.g. shaking or tilting) is available. This can exclude people with motor disabilities.

In conclusion

This was a lot to digest in under two hours. However, these base recommendations are so critical in order for people with disabilities (and everyone else) to be able to operate, navigate, understand, and appreciate a site and its services. I cannot afford to glaze over them, but rather advocate for at least this bare minimum in sites I collaborate on.

Day 67: How to Fail the Bare Minimum of WCAG Perceivable

The next few days are going to feel like review. And, yet, the next few days should bring satisfaction of putting some of this knowledge to use.

Today I landed on looking over WCAG’s perceivable principle again in order to focus on the success criteria at the base conformance level, and dug into sufficient and failure techniques. My intention at this point in my journey was to approach this with another person’s perspective, and better understand how content and components might inadvertently be “invisible” to anyone who has a visual or auditory impairment or makes use of assistive technology.

Things I accomplished

  • Read Perceivable success criteria (Level A) failure techniques on How to Meet WCAG 2 site.
  • Mapped success criteria to failures of those criteria that I’ve encountered.

What I learned today

There are 9 bare minimum (Level A) success criteria recommended by W3C in order for websites to be perceivable (seen, heard, touched). These success criteria are, as follows:

  • 1.1.1 Non-text content
  • 1.2.1 Audio-only/Video-only (pre-recorded)
  • 1.2.2 Captions (pre-recorded)
  • 1.2.3 Audio description or media alternative (pre-recorded)
  • 1.3.1 Info and relationships
  • 1.3.2 Meaningful sequences
  • 1.3.3 Sensory characteristics
  • 1.4.1 Use of color
  • 1.4.2 Audio control

When these nine perceivable success criteria are met, it enables people with visual impairments and hearing impairments to enjoy your content and interactive components.

Examples that fail base conformance

SC 1.1.1 Fail: Customized radio buttons in a survey were invisible to me when I was using Windows High Contrast Mode. That’s because they used a background-image to replace the actual radio button, which was also set to opacity=”0″. This failure results in excluding people with visual or cognitive impairments who use HCM or custom stylesheets.

SC 1.2.1 Fail: Audio files of a recorded meeting do not have a transcript or long description that provides equivalent information in text format for people who have a hearing impairment.

SC 1.2.2 Fail: So often do I see recorded video with sound, but no captions are provided. As a note, YouTube does provide auto captioning which can be sufficient to meet SC 1.2.2, but could result as a failure if the captioning is not accurate and could leave out important information. A manual check may be necessary. This failure excludes people with hearing impairments.

SC 1.2.3 Fail: Also, another common fail. People don’t realize this is not a nice to have feature. Leaving out audio description in a video that has a lot of undescribed actions within the video is a fail at WCAG’s most basic level. This can exclude people with visual impairments.

SC 1.3.1 Fail: Another recent fail I found in an ongoing accessibility audit was the discovery of tables with out row or column headings identified. The relationship of the data isn’t explicit and may exclude people with visual impairments.

SC 1.3.2 Fail: Related to the prior fail of SC 1.3.1, I also found tables that were used for layout rather than relational data. This can confuse people who use screen readers (visual and cognitive impairments) when a table is read aloud, but the content’s relationship is meant to convey something else.

SC 1.3.3 Fail: I see this failure a lot in content I receive to post online. Within the content, a spatial location is inserted (e.g. “the photo to the right”). This is not only meaningless to people with visual impairments. It also is meaningless to mobile users who see a different layout on their smaller screen, but that isn’t an accessibility issue.

SC 1.4.1 Fail: Surprisingly, I still run across input error messages that stand out in red, but don’t offer any other indicator that the user has made an error. This can exclude people with visual disabilities from submitting forms.

SC 1.4.2 Fail: The days of inserting background music on a webpage seem far behind us, but what about those ads that autoplay on a webpage? If the autoplay doesn’t have a pause or close button, the page fails SC 1.4.2. I haven’t run across this fail personally, but it would interfere with a screen reader users interaction with the page due to the uncontrollable interruptions. Not to mention, how annoying that would be to everyone else visiting the site.

In conclusion

I’m horrified that many of the most basic success criteria still fail on a regular basis across the web. None of these are even new in WCAG 2.1. What really astounds me is how easy and inexpensive most of these techniques are to follow. Captions and audio descriptions aside, since those are usually outsourced and need to be budgeted, the other seven leave no excuses, in my mind. We need to do better to make the bare minimum part of business (development) as usual, and not even consider them an accessibility issue, but rather as best practice in content creation, design, and development.


Day 66: Circling Back to WCAG and Other Standards

Getting myself organized this week to continue studying is proving a bit challenging. The next section I’ve segued into within the WAS Body of Knowledge (BOK) is Section II list item B: Determine conformance to accessibility specifications based on accessibility issues found.

Suggested study topics within that section include:

  • Re-familiarizing myself with the specifications (WCAG, WAI-ARIA, and ATAG), and determine which success criteria apply to which conformance level.
  • Distinguish between failures of accessibility criteria versus other bad accessibility practices that are not referenced in one of these specifications.

It took me a lot of re-reading this section several times to finally decide how to proceed, what I needed to focus on, and divide up each day of this week.

Things I accomplished

  • Interpreted the WAS BOK study material to determine a course of action this week.
  • Began review of my WCAG cheat sheet to prepare for mapping failures to success criteria.

What I learned today

The first thing that confused me when I first read this part of the BOK was the mention of pointing out accessibility failures, but don’t point all of them out. What?! A failure is a failure, and something that’s inaccessible is inaccessible, right? What finally dawned on me was that I was thinking just in terms of WCAG, especially since WCAG was used as examples throughout. This section is really saying,

  1. Find out what conformance level you have to measure your client’s site against.
  2. When a failure is found, cite the criterion that it failed.
  3. Don’t point out accessibility issues that are not within the measuring stick of which you are using.

After 66 days of focusing on web accessibility, I’ve found that I’m retaining things better than I hoped, understanding concepts more deeply, and can quickly research something now that I have so many resources and correct terminology at hand. The biggest transition that is happening in my brain is the change of focus from technicalities (code and standards) to a focus on the people using our sites and the challenges they face. The standards are still important to me, but they are more of a means to achieve my goal of enabling people with disabilities to surf the web just like everyone else. Technicalities worked as a good starting point. However, starting with understanding (empathizing with) people and the barriers they face would seem to be an even better place to start, so that the technicalities come easier.

This image comes to mind when expressing Tim Berners-Lee’s dream to build an open web that’s for everyone:

Lights around a stadium spelling out

Caption: Lights around the London’s 2012 Olympic stadium describe Sir Tim Berners-Lee’s invention, the world wide web. The Open Data Institute, which he co-founded, declares a mandate of ‘Knowledge for Everyone’. Photograph: Martin Rickett/PA

All that being said, this week I’m going to enjoy putting the puzzle pieces together when it comes to mapping failures with standards, all the while, reinforcing the reasons behind those standards (the people!).

Day 65: Identifying A11y Issues for Switch Control Users

About a week ago I learned more about users with motoric disabilities, which is usually who I think of when it comes to switch device use. Today I wanted to focus more on what challenges switch device users may encounter when using websites. My study time ended up turning into review of some things I’d already learned, as well as discovering some new articles and videos about switch access.

I was not able to do any testing myself, since I don’t have any switch devices. On another day, when I’m feeling more adventurous, I’ll dedicate a study session to testing with a Bluetooth keyboard or Android device buttons to simulate the experience.

Things I accomplished

What I learned today

Apple’s Switch Control feature is built over the VoiceOver platform, so that’s how it knows to recognize things like buttons. Point mode allows access to otherwise inaccessible apps by scanning horizontally and vertically (x, y coordinates) to create clickable point. It also gives an alternative for quicker access to focuable elements on a web page, rather than waiting for a page to be parsed and scanned piece by piece.

After learning more about switches and switch control, I can better understand the many switch control settings on my iPhone.

I usually think of switches being used by people with motor disabilities, but there are other people who use it, too. Some people with intellectual or learning disabilities may use a switch because a mouse, keyboard, or game controller is just too complex to use.

Switch access includes devices that can receive input from almost any body part. Actions may include, but are not limited to:

  • sip-puff
  • push
  • pull
  • press
  • blink
  • squeeze
  • twitch

Windows 10 has eye control as a method of switch access. Apple doesn’t have this feature… yet.

Android mobile devices have switch access much like Apple’s feature.

In review of what I learned last week

Restating from my article mentioned at the beginning, designers and developers need to review WCAG’s operable principle for switch control accessibility. It can’t be emphasized enough that if your website is following those guidelines and success criteria, your website will be accessible to switch users and many other users.

What front-end developers can do for switch control users:

  • make the website keyboard accessible so all elements are reachable
  • place key elements above the fold to relieve tedious scrolling
  • allow alternative to advanced gestures, like hover over and drag-and-drop
  • use larger text for readability from a further distance of user between screen
  • avoid time limits or allow user to increase time limit
  • tolerates user error
  • provide alternative navigation methods to skip over lists of links, repetitive sections, and lengthy text
  • offer autocomplete, autofill, or autosave
  • manage off-screen items appropriately (display:none, visibility:hidden when out of view)
  • provide clear focus outlines



Day 64: Experimenting with Dictation & Speech Recognition

While working through my study session a few days ago about identifying a11y issues for people who use voice input to navigate the web, I ran across an interesting tweet thread started by Rob Dodson:

So funny that this stuck out on my feed last night as I was finishing up my blog post! Admittedly, it sparked my curiosity about how ARIA affects voice dictation users, and spurred me on further to start testing with the different platforms that are available to people who need full voice navigation.

Things I accomplished

  • Experimented with Apple Dictation and Siri combination (with brief use of VoiceOver)
  • Experimented with Windows speech recognition in Cortona company
  • Attempted to write some of this blog post with a combination of Apple Dictation and Windows Speech Recognition.

What I learned today

Disclaimer: I am not a voice input software user. This is VERY new to me, so lean very lightly on my “experience” and what I’m learning.

Learning curve and first-use exposure aside, Apple’s Dictation feature didn’t seem to have enough reach or intuition to do the multitasking I wanted to do. Additionally, I found that I had to keep reactivating it (“Computer…”) to give commands. There was no continuity. Apparently, I’m not the only one disappointed with the lack of robustness Dictation + Siri has to offer. Read another person’s feelings in Nuance Has Abandoned Mac Speech Recognition. Will Apple Fill the Void?

Here is Apple’s dictation commands dialog that I had off to the side of my screen as I worked with it enabled:

Apple Dictation Commands dialog, starting with Navigation.

The number system to access links appears to be universal across dictation software. I found it in Dictation and Speech Recognition. And I know Dragon has it, too.

Windows Speech Recognition was just as awkward for me. However, I felt it was built more to include navigating my computer, and not solely dictation of documents. Microsoft has a handy Speech Recognition cheatsheet.

Here is the Windows Speech Recognition dock, that reminds me of what I’ve seen online with Dragon software:

Speech Recognition dock "Listening".

I found myself struggling to not use my keyboard or mouse. If I had to rely on either of these OS built-in technologies, I think I’d definitely invest in something more robust. Eventually, I want to get a hold of Dragon NaturallySpeaking to give that a try for comparison.

For people who can use the keyboard along with their speech input, there are keyboard shortcuts to turn listening on and off:

  • Apple: Fn Fn
  • Windows: Ctrl + Windows

By far, this was the hardest thing for me to test with. I think that’s due to the AI relationship with me and my computer. It was nothing like quickly turning on another piece of software and diving right in. Instead, it required that it understand me clearly, which didn’t happen often. Ultimately, it will take some time for me to get comfortable with testing my web pages with speech recognition software. Until then, I’ll be heavily leaning on other testing methods as well as good code and design practices.

As a final note, based on the above statement, I think purchasing more robust speech recognition software, like Dragon, would be a harder sell to my employer when it comes to accessibility testing. It’s a hard enough sell for me to want to purchase a Home edition license for my own personal use and testing freelance projects.

Day 63: Practice with JAWS

Back to playing with assistive technology. I wanted to mess around with speech input software, but I started the process and realized that will be a weekend project, due to the learning curve. So I settled on working in JAWS today to continue learning assistive technologies and what experience they provide.

Note: JAWS is really robust and considered top-notch in the screen reader industry. By no means, am I an expert at using JAWS. However, I need more practice with it, since I lean more heavily on NVDA for screen reader testing.

Things I accomplished

What I learned today

JAWS stands for “Job Access With Speech”.

The cursor on the screen blinks REALLY fast when JAWS has been activated.

Some of JAWS basic keyboard commands are very similar to NVDA’s (or vice versa). That was extremely helpful when experimenting with it. That made me happy when thinking about one of my blind friends that recently made the switch from JAWS to NVDA. It likely made her transition a whole lot easier! (now I’ll have to ask her about it)

I used Insert + F3 a lot to move more quickly through a page’s regions and interactive areas. I liked how many options I had on their built-in navigation feature. However, I did accidentally discover a browser difference with Virtual HTML Feature when I switched over to my Firefox window to add notes to this post (colors are funny because my system was in High Contrast Mode at that time).

Firefox with Insert + F3:

JAWS Find dialog window.

IE with Insert + F3:

Virtual HTML Features dialog.

The built in PDF reader in IE didn’t seem to register any regions with the Deque cheatsheet, like NVDA with Firefox did. So I couldn’t quickly navigate between tables within the browser.

I really like how I could sort links by visited, unvisited, tab order or alphabetically! Plus, I could either go to link or activate the link as soon as I found it in this list.

JAWS Links List dialog.

JAWS had a few more customization choices than NVDA:

JAWS Settings Center dialog.

My bad: I inadvertently found a few photos on a site I manage that needs some alternative text because they are not decorative.


Day 62: Identifying A11y Issues for Voice Input Users

Speech input software is an assistive technology and strategy that people use when they have difficulty using a keyboard or mouse. This may include people with motor, visual, or cognitive disabilities. In the 21st century, it’s an excellent alternative for people in all walks of life.

Things I accomplished



What I learned today

Windows 10 has built-in speech recognition?? It sounds like a combination of Cortana and Speech Recognition could be a cheap alternative to Dragon, but I’d need to experiment a bit with both to compare.

Apple has a Dictation feature. So, somewhat like Windows, a combination of Siri and Dictation could be used. I’ve avoided setting up dictation just because of the privacy flag that pops up when it asks permission to connect to an Apple server and learn from your voice over the Internet. Maybe I’m just paranoid and they all actually work that way?

Dragon offers some ARIA support, but it appears to be limited, and should be tested if relying on aria-label, specific roles, etc.

Love this catchphrase from the Web accessibility perspectives video:

“Web accessibility: essential for some, useful for all.”

Challenges that people who use speech recognition software face on the web:

  • carousels that move without a pause button
  • invisible focus indicators
  • mismatched visual order and tab order
  • mismatched linked image with text and alternative text
  • duplicate link text (e.g. Read More) that leads to different places
  • form controls without labels
  • hover only menus (MouseGrid can struggle accessing these)
  • small click targets
  • clickable items that don’t look clickable
  • too many links

Designers and developers should focus on WCAG’s Operable principle. In particular, Navigable guideline’s success criteria would apply here. If many of those success criteria are met with other users in mind, it will definitely be beneficial to speech recognition users, too.

In the past, I haven’t personally been interested in software, like Dragon, yet looking from an accessibility point of view, I’m ready to start testing with speech input technology to better understand how it works and affects people who rely on it when interacting with the web.

Day 61: Identifying A11y Issues for Users Who Magnify Their Screen

Things I accomplished



What I learned today

Windows has a built-in magnifier, as does Apple, but it often isn’t always strong enough or robust to help everyone with low vision. Alternative magnification software includes:

For mobile, I knew Apple phones and tablets had zoom built in, but Android devices have magnification built-in, too.

Apple Watch has a zoom feature (YouTube)!

Trying to learn all things accessibility, I’m constantly having to rediscover keyboard shortcuts:

  • Windows Magnifier: Windows + +
  • Apple Zoom: Option + Cmd + 8


Never assume that two low vision people are alike. Everyone with low vision has their underlying reasons of why they struggle with that disability. The point is to add flexibility for their particular experience with low vision and the strategies they use to access content and services on the web.

Challenges people who enable magnification may encounter on the web:

  • text as images become blurry and pixelated when magnified
  • unclearly marked sections/landmarks can make navigation slow when a user only see a small portion of the screen and they’re trying to differentiate navigation from main content from a footer
  • headings that look too much like paragraph text
  • unclear link text
  • scrolling, flashing, or moving objects (carousels, I’m glaring at you again)
  • drawn out content that doesn’t provide a quick intro or conclusion at the beginning
  • horizontal scrolling
  • page content referred to by it’s position (e.g. “to the right”)
  • meaning is conveyed by color alone
  • forms with fields and labels that are not close together or positioned on one line together

WebAIM’s advice:

“The general rule when designing for low vision is to make everything configurable. If the text is real text, users can enlarge it, change its color, and change the background color. If the layout is in percentages, the screen can be widened or narrowed to meet the user’s needs. Configurability is the key.”

WCAG supports people with low vision through it’s perceivable principle. 15 reasons to consider designing to include low vision users who magnify their screen:

  • 1.1.1 Non-text content (A)
  • 1.3.1 Info and relationships (A)
  • 1.3.3 Sensory characteristics (A)
  • 1.3.4 Orientation (AA)
  • 1.4.1 Use of color (A)
  • 1.4.3 Contrast (minimal) (AA)
  • 1.4.4 Resize text (AA)
  • 1.4.5 Images of text (AA)
  • 1.4.6 Contrast (enhanced) (AAA)
  • 1.4.8 Visual presentation (AAA)
  • 1.4.9 Images of text (no exception) (AAA)
  • 1.4.10 Reflow (AA)
  • 1.4.11 Non-text contrast (AA)
  • 1.4.12 Text spacing (AA)
  • 1.4.13 Content on hover or focus (AA)