Mobile App Accessibility Prototyping

A lot of accessibility issues can be already foreseen and prevented in the design phase. You can save time checking and documenting accessibility mockups. In this article, I cover color usage, contrast ratios, text resizing, font legibility, target sizes, form elements, focus order, complex components keyboard interactions, skip links, headings, landmarks, and alternative text for images. The tips in here are focused in Figma, but can be applied to other tools. https://lnkd.in/eu8YuWyF

Prototypes have always been hard to test with screen reader users because the prototypes aren't accessible enough for them to interact with. When Vercel first launched v0 in October 2023, there were many concerns about the accessibility of the prototypes it produced. I've been using v0 for the last few weeks and checked out the current state of accessibility on a demo SaaS landing page: https://lnkd.in/g6rfbWpx I used a templated prompt "Create a modern, responsive landing page for a fictional SaaS company. The landing page should include the following sections: * A header with the company logo, navigation links, and a call-to-action button. * A hero section with a catchy headline, brief description, and a prominent call-to-action. * A features section highlighting 3-4 key features of StreamLine. * A testimonials section with quotes from satisfied customers. * A pricing section with different plan options. * A final call-to-action section to encourage sign-ups. * A footer with important links and social media icons." What I found - Good: * Proper use of headings * Good contrast (overall, but not perfect) * Used landmarks correctly * Good semantics (uses buttons and lists instead of divs) * Proper aria and focus on mobile menu, supports escape key to close Bad: * Screenshot alt text should be more descriptive * Hover states need better contrast * Testimonials headshots alt text is repetitive (repeats the customer name) * Nav regions should each have a unique name * Ghost button contrast is really low * Two instances of grey on grey subheadings that have poor contrast Second prompt "Make sure it's accessible to people with disabilities" and it changed the following: Fixed: Screenshot alt text to be more descriptive Not fixed: Hover states still need better contrast Not fixed: Added "portrait of" to testimonials headshots Fixed: Nav regions now have a unique name Not fixed: Ghost button contrast Not fixed: Grey on grey subheading contrast Added: Moved navigation links into lists I thought v0 did a decent first attempt and even better after the accessibility prompt. Only a few tweaks would be needed for a very accessible experience. Even without the tweaks, it's good enough for a screen reader user to give feedback on, without me having to do any manual intervention. Some folks are concerned about the environment impacts of AI, but a comparison of v0's energy use (including amortized estimates on training), was a total per prototype of ~0.2–0.8 kg CO₂e compared to a human spending time building the same prototype of ~0.5–1 kg CO₂e. All in all, I'm pretty excited about where AI will be taking accessibility in the future.

I NAIVELY thought our prototype wouldn’t raise that many accessibility issues... Accessibility testing = a humbling process! As an interaction designer working on a government service, I worked with the rest of my team to develop our prototype in the GOV.UK prototyping kit. The kit is excellent. All the components have already been tried-and-tested, and it allows government designers to build something quickly, that can be tested with all users. Prototyping in code is the ONLY way to ensure the service is accessible. If you create a Figma prototype, you can’t fully test it with people who use screen readers or other assistive technologies. Carrying out accessibility testing was a large part of our research plan. We needed to make sure the service worked for everyone. Since we were using existing components, I thought the changes that needed to be made after testing would be minimal. We found more issues than I imagined!! Here are some of them; Glitches in the HTML which meant that people couldn’t read one of the tick-boxes on the form. A link below a ‘Continue’ button which meant a screen-reader user completely missed that part of the page. An issue on a page where the user selects something, and they’re taken straight to the next page unexpectedly. A page where we just had too many buttons and it was overwhelming for people. I’m now in the process of completely redesigning some of the more problematic pages. Accessibility testing was a hugely valuable process, which highlighted issues I could not have predicted.