Tag: accessibility

YNAB adds a Home screen to its iOS mobile app; but is it accessible?

Author Rachele DiTullioPosted on Categories MobileTags ,

I’m a longtime YNAB (You Need a Budget) customer. I use their monthly planning software every day to track my expenses and manage my budget. I’ve written about their webapp accessibility previously and noted over the years that they have made updates to improve the experience for disabled users, such as adding dark mode support.

Yesterday when I opened the app, I noticed it looked different. The bottom tab bar navigation changed and the new first tab was called “Home” with a screen that looks something like a dashboard.

YNAB home screen showing money available to assign, top priority of savings and a September summary of budgeting and spending

Whenever I see something new in an app I use frequently, I like to turn on the VoiceOver (VO) screen reader on my iPhone 12 mini and explore the interface. I found a few critical issues where VO users simply cannot access some controls, as well as a few other Level A failures that should be addressed soon.

I did notice that YNAB put out an updated release this morning to Version 25.26 which has fixed some other issues, such as the “Transaction” button not having an accessible name of “Add Transaction” even though it relies on the plus icon for sighted users to understand the button’s purpose.

Let’s look at one of the critical issues YNAB should resolve to make the new “Home” screen more accessible.

Assistive technology users cannot select options from the ellipsis button context menu

In the upper right of the screen is a circular button with an ellipsis icon in the middle. The button doesn’t have an accessible name but does announce the “button” trait/role so VO users know its interactive and the “pop up button” attribute so VO users know the button will open a menu.

screenshot of the ellipsis button on the YNAB Home screen. VoiceOver caption panel shows an announcement of button, pop up button.

When I double-tap the unnamed button, a context menu opens with four available actions: Open Plan, Hide Amounts, Support and Settings & Privacy. When the menu appears on screen, focus moves to the first item in the list, “Open Plan”. While the “Open Plan” control is missing the button trait/role, it can be double-tapped by VO users to activate.

Unfortunately, assistive technology (AT) users cannot access the other three controls below “Open Plan”. When a VO user swipes to go to the next option in the list, focus moves outside the list to a button with an accessible name of “Dismiss context menu”. VO users cannot swipe to other content on the screen because focus is trapped. Their only option is to dismiss the menu to continue.

screenshot of the YNAB home screen with the ellipsis context menu expanded to show four options. VoiceOver is stuck on an invisible button announcing Dismiss context menu, button.

I tried accessing the menu options using a Bluetooth keyboard and Voice Control speech input but was unable to select any of the menu options using those AT methods. This menu is actually a keyboard trap as keyboard users cannot close the menu to continue on the “Home” screen and have to restart the app. Here’s a video of the VO interaction with the ellipsis button and context menu

The overall accessibility of the new “Home” screen is pretty good but the design seems to break down when there are more complex controls. It’s great that YNAB has an accessibility statement on its website; I’d like to see a link to that in the mobile app too, along with the new Accessibility Nutrition Labels listed in the App Store.

Accessibility testing spreadsheet version 2

Author Rachele DiTullioPosted on Categories Mobile, WebsiteTags ,

I’ve updated the spreadsheet I use for tracking accessibility audits with three big additions.

Download the accessibility testing spreadsheet (Updated 26 January 2024)

WCAG 2.2 success criteria added

I’ve added the six new WCAG 2.2 level A and AA success criteria (SC) to the “WCAG Success Criterion” column in each component’s tab. This brings the total number of SCs for an audit to 55. (4.1.1 Parsing is deprecated but still included for 2.1.) Each new SC is highlighted in light green and includes “NEW in 2.2” in its name.

If you’re not ready to test for WCAG 2.2 SCs, just mark them as N/A.

WCAG failure tracking

I’ve added rudimentary tracking of the number of WCAG violations found for each component which is displayed on the “Scope” tab in the a new “WCAG Violations” column. Each cell counts the number of “Fails” selected in the “Status” column of each component’s tab.

On the “Overview” tab, you can see a running total of all WCAG violations found for all components in the audit.

Prioritizing issues

I’ve also added a “Priority” column to each component’s tab. Each SC can be assigned a priority on a five-point scale:

  1. Critical – Blockers that prevent someone from completing a task, e.g. a button that cannot be used with a keyboard​
  2. High – Issues that present a significant barrier to someone completing a task, e.g. application times out without allowing the user to extend it
  3. Medium – (Most issues) Issues that present a barrier to some users from fully accessing the information or interface, e.g. text has poor color contrast​
  4. Low – Issues that present an unnecessary barrier but do not prevent a user from completing a task, e.g. image text that isn’t sufficiently descriptive​
  5. Best Practice – Issues that present some accessibility barriers but are not considered failures under the Web Content Accessibility Guidelines (WCAG), e.g. using a button instead of a link to open a webpage in a browser

If you have any questions about the spreadsheet or additions you’d like to see, please contact me.

Autocomplete accessibility bookmarklet

Author Rachele DiTullioPosted on Categories Desktop, WebsiteTags , ,

Drag the autocomplete bookmarklet to your bookmarks bar.

I created this bookmarklet for testing WCAG success criterion 1.3.5 Identify Input Purpose (AA) which requires that if an input field requests personal information about the user, we must apply the appropriate autocomplete value to the field. For example, an input field requesting the user’s full name would have an attribute of autocomplete="name". This allows the browser to attempt to autofill the input field with previous values entered for the same information. It is very much browser-specific.

Amazon create account form with a Your Name field. The letters R A are entered into the field and autocomplete shows five variations of the name Rachele DiTullio.
Amazon create account screen in Firefox

This bookmarklet checks the webpage for any input fields that contain the autocomplete attribute. If none are found, it returns an alert message.

a google.com alert message that says No input fields with autocomplete attributes found on this page.
Alert message on the Google search page

If autocomplete attributes are found, the script returns the values and displays them in context of the input field.

A form showing five form fields all with autocomplete values defined.
TPGi.com signup form with autocomplete values

This makes it easy to determine if input fields have autocomplete attributes defined and if they are valid. Click the bookmarklet again to remove the overlay text.