This month at work, we’ve started using new time tracking software for submitting our timesheets. The process for submitting a timesheet in this system is a truly cursed design pattern. Behold, the “Submit Timesheet” button.
I tried clicking on the “Submit Timesheet” text and nothing happened. I expected this text to be a button because it’s supposed to submit the timesheet, but no, this is not a button.
I asked myself, “Why is there an error icon?”
Then I hovered the mouse cursor over the error icon and saw this:
It’s not very obvious, but this control looks like a switch. When I inspected the switch, this is what I saw, simplified:
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.
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.
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.
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.
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:
Critical – Blockers that prevent someone from completing a task, e.g. a button that cannot be used with a keyboard
High – Issues that present a significant barrier to someone completing a task, e.g. application times out without allowing the user to extend it
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
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
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.
