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

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

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.

5 neurodivergent UX fails while buying Alamo Drafthouse tickets online

I went to the movies this week for the first time since the pandemic began. I looked up showings at the Alamo Drafthouse and discovered little has improved with their payment process since I reviewed it on desktop back in 2016. This time, I completed the purchase on an iPhone using the responsive mobile website in the Firefox browser.

While I found several accessibility issues with the site, I’m highlighting concerns with the “Payment” screen. I’m neurodivergent and this post focuses on five things that cause me anxiety and make the experience frustrating:

  1. Required fields are not marked
  2. Submit button is disabled
  3. Error messages don’t offer suggestions
  4. Data formats are placeholder text
  5. Optional checkbox is already checked

Required fields are not marked

I’ve done enough online ordering that I assumed that all the credit card-related fields are required, but many people will not understand that. E-commerce research suggests that marking all fields, required or optional, improves the customer experience. It certainly lessens my anxiety to know exactly which fields to complete.

screenshot of the payment screen with form fields with placeholder text for Card Number, Cardholder Name, EXP, CVV and Zip code. The "Buy Tickets" button is disabled.

Not only are required fields not clearly marked, but merely interacting with a field causes the display of an angry, red “Required” message. (This does not work for the “EXP” field even though it is required.) These input fields use a combination of the HTML required attribute with an aria-describedby attribute for the error message which causes assistive technology to announce fields are required multiple times.

screenshot of the payment screen with red error messages denoting several fields are required

Submit button is disabled

From the previous screenshots, we can see the next issue that causes me a lot of anxiety when using a website. The “Buy Tickets” button, which is the submit button for the form, is disabled by default. The button becomes enabled only after data has been entered into all the required form fields, which are not clearly marked.

There are two more required form fields below the credit card fields but they are easy to miss because of the sticky footer with the “Buy Tickets” button, meaning that after entering all credit card details, this button is still disabled.

Error messages don’t offer suggestions

The default error message for empty fields is “Required”. If a user enters data in the wrong format, the error messages change to “Invalid”. This doesn’t help the user in any way to figure out how to fix the error.

screenshot of the payment screen with bad data entered into several fields which each have an error message of invalid.

Here are some examples of helpful error messages:

  • Card Number: Please enter 16 digits
  • EXP: Please enter 2-digit year
  • CVV: Please enter 3 digits
  • Zip Code: Please enter 5-digit US zip code

“Zip Code” is the only field requesting numerical data that displays the numerical keyboard on mobile devices. Adding the inputmode="numeric" attribute to every field requesting numerical data will display the numerical keyboard too, which improves the accuracy of data entered into these fields.

Screenshot of the payment screen with focus in the Zip Code field which displays the 10-key numerical keyboard on mobile devices

Data formats are placeholder text

The requested data format for all the “Payment” screen fields are implemented as placeholder text. This means that once a person starts to enter data into the field, the required formatting of that data disappears. People are forced to recall from memory how to enter the data correctly. On top of this, the “EXP” and “CVV” fields allow someone to enter more digits than the data format allows.

The video below demonstrates what a person using assistive technology, like a screen reader, experiences when exploring the form. Notice how placeholder data are not consistently announced by VoiceOver.

Optional checkbox is already checked

Following the credit card-related fields is the “Email Confirmation” section which includes a checkbox that is already checked:

Join Alamo Victory

By checking “Join Alamo Victory” you start earning visits with this purchase for rewards and you agree to Alamo Drafthouse Cinema’s terms of use.

Email confirmation section with email address and confirm email address fields followed by a checkbox that is already checked for Join Alamo Victory

This is an optional field. It should require that I choose to check it. Because of its location behind the sticky footer, it’s very likely people will not see this checkbox and inadvertently join this program. Having to look for sneaky UI patterns like this makes for a bad experience.

Conclusion

This website has made some improvements like providing a “Back” button after timeout and inline form field validation. I also give the developers kudos for appropriately implementing the autocomplete attribute on the credit card-related fields. I’d make the following changes to the “Payment” screen to create a better experience for neurodivergent people:

  1. Clearly indicate which form fields are required
  2. Don’t disable the submit button
  3. Offer suggestions for fixing data input errors
  4. Display required data formats at all times
  5. Don’t pre-check checkboxes for optional promotions