Skip to main content

axe-con 2024: Day Three (Haley)

Accessibility
Team Insights

Pixel-Perfect is Dead, Long Live to Adaptive and Accessible iOS Apps

Speaker: Daniel Devesa Derksen-Staats

This talk ended up being a bit more technical and iOS centered than I expected, but there were definitely some interesting takeaways that can be applied to UI design and website development. The biggest one, in my opinion, was about dynamic type sizes. I think that sometimes I get too focused on how type looks in the “normal” view of a screen that I’m designing, and I sometimes forget to consider how that same screen might look with different text size settings. Daniel Devesa made a few key points that resonated with me as a UX designer:

Dynamic type sizes

UIKit/Swift UI provides 12 type sizes and 11 styles that automatically resize based on user preference while maintaining the appropriate visual hierarchy. When defining custom type, we should ensure that each heading, paragraph, caption, etc. resizes appropriately based on the zoom level/screen size.

Dynamic spacing between elements

Spacing between two text components automatically adjusts to the ideal spacing depending on the user’s type size preference. When adjusting type sizes based on zoom level/screen size, we should also ensure that spacing between two different text components adjusts to prevent awkward spacing.

Vertical vs. landscape device orientation.

I know I have a tendency to just use a simple media query that checks the device width in order to adjust styles. This can have unintended consequences. On a phone in landscape mode, for example, the type may be using a larger pre-defined size, but because the screen height is very small, only a small amount of text is visible on the screen.

These are definitely things that I will pay more attention to moving forward!

Inaccessible Marketing Emails Suck!

Speaker: Erik Gustafsson Spagnoli

We always talk about improving web accessibility, but email design and implementation always seems to be a step behind. In his talk, Erik Gustafson Spagnoli compared HTML emails and highlighted the differences between what makes an email good (accessible) or bad (inaccessible).

Common examples of “bad” email design choices:

  • Not including useful alt text on images - if the image is truly decorative, then this is less of an issue, but when the image conveys some sort of meaning or data, then missing alt text can prevent users from getting all of the information that they need.
  • Embedding buttons/call to action links in images - if images are not loaded (either because of a user preference or poor internet connection) then users will not be able see the button that they need to click for more information. This is especially bad when the image is missing alt text.
  • Not checking the appearance of the email in dark mode - many email clients switch to dark mode automatically, which can result in poor text contrast if you aren’t careful (for example, if text color changes but button background color doesn’t, then that button will be unreadable).
  • Making the unsubscribe link hard to find or mislabeling it - many emails say some variation of “to unsubscribe from emails, click here,” which is an extremely poor choice of link text.

Good email design practices:

  • Avoid embedding text/buttons in images (but use appropriate alt text if you can’t avoid it).
  • Test how your email looks without loading the images. To improve the display of emails without images, add width and height attributes to the image to preserve your email layout (bonus: add a background color behind the image to make it clear that this space is normally filled with an image)
  • Always add alt text and ensure that alt text is translatable like the rest of your email content.
  • Check how your email displays in dark mode and adjust any inconsistencies.
  • Ensure the unsubscribe link (or any link, for that matter) is clearly labeled and easy to distinguish from non-linked text.

Text-To-Image Accessibility

Speaker: Mary Ann Jawili

In her talk, Mary Ann (MJ) Jawili talks about Adobe Firefly and the improvements that the product team is making to help blind and low vision users generate and select images based on text prompts. Nowadays, AI-generated images are becoming pretty common, but there’s still a lot of work to do to help people who can’t see the generated image variations select the one that they want to use for their intended purpose.

What could help blind/low vision users choose which AI generate image to use?

  • AI calculates a prompt-image similarity score. This score can be helpful in comparing the generated image variations for accuracy.
  • AI generates detailed descriptions of the meaningful differences and similarities between each image variation.
  • AI detects any mistakes and discloses them to the user (should images with mistakes even be included in the results?)
  • Provide a way for users to ask questions about what else is included in the image. AI can respond to these questions and remember to include these details in the future.

All of this work is currently in progress. As of right now, AI chatbots are not the best at generating completely accurate alternative text from an image, so I’m interested to see how Adobe Firefly continues to enhance its product for blind/low vision users over time!

Using the WebAIM Million and User Surveys to Inform Accessibility Efforts

Speaker: Jared Smith

The WebAIM Million started testing 1,000,000 top homepages in 2019 and continues to test every year to gather accessibility insights over time. Jared Smith shared lots of statistics and shared that while accessibility is improving, those improvements are happening extremely slowly. In fact, in 2023, 96.3% of homepages tested had detectable WCAG 2 failures. That, to me, was shocking to see!

Pages with most common errors:

  • 84% of pages had low contrast text
  • 58% of pages had missing alt text
  • 50% of pages had empty links
  • 46% of pages had missing input labels
  • 28% of pages had empty buttons
  • 19% of pages had missing document language

These numbers are unfortunate because these errors are super basic in terms of complexity. However, this is also encouraging because if websites could just fix these simple errors, we would see a massive increase in web accessibility overall.

Some other interesting statistics:

  • Drupal websites had 20% fewer errors than average!
  • 10% of users reported using VoiceOver (Mac) as their screen reader of choice, but it was used 3 times more often by users without disabilities. This suggests a mismatch between designers (who tend to use Macs) testing websites with VoiceOver even though users with disabilities tend to use other technologies.
  • While there was a measurable increase in ARIA attributes detected on pages, more ARIA attributes correlated with an increased number of accessibility errors. ARIA menus were a top offender.

How Do You Make Accessibility Testing as Efficient as Possible?

Speaker: Harris Schneiderman

In this presentation, Harris Schneiderman demoed three different accessibility testing tools that fit into different stages of the website design/development process. The tool that was particularly interesting to me as a UX Designer was the Figma plugin axe for Designers. There were three functions that were showcased:

Scan your design for accessibility issues

With just the click of a button, this plugin scans an entire frame and lists every accessibility issue that it finds. It highlights where in the design each issue is located, describes the issue, and suggests ways to fix it.

Check color contrast of individual elements

With this tool, you can select an individual element and quickly test the color contrast between the foreground and background. If the element has low contrast, the tool suggests other colors that you can use instead.

Annotate the elements of your design

This tool allows you to select an element in your design and choose the type of element it is as well as any roles or attributes the element should contain. It then places the annotation directly in your design next to the element. This is a great way to quickly annotate designs before handing them off to a developer.

After seeing the demo, I will definitely be looking into the axe for Designers Figma plugin!

Helping Debunk Disability Stigma

Speakers: Squirmy and Grubs

For an in-depth review of this talk, take a look at Riley's axe-con Day Three article.