For a blind technology user like myself, digital accessibility is paramount in online banking. Once I can manage my finances online, I can enjoy all the rest the Internet offers. Having control over my money is huge for my independence.
Almost all modern banks provide a website or mobile application that allows customers to pay bills, transfer money, set weekly or monthly budgets, and much more. The good news is that most banking sites are doing a lot to provide an intuitive, usable, and accessible experience for assistive technology users like myself.
While I have covered online banking accessibility in the past, I wanted to provide a detailed running account of a specific experience that will help to demonstrate how some of the theoretical issues I have discussed affect real-world browsing sessions. As I narrate my journey, I will point out both positive and negative accessibility points. As always, screen reader accessibility will be my primary area of focus.
Initial Smooth Sailing
Upon launching the particular banking website, I immediately began my usual exploration when visiting an unfamiliar website. The site's homepage was relatively simple in design. Properly labeled links or buttons represented action items such as sign-in, open an account, contact help, and report fraud. Since my task was related to account opening, I found and activated the relevant option. The next screen gave me the choice to select the type of account I was interested in opening. The choices, checking account, savings account, credit card, or investment account, were organized in a simple list that my screen reader clearly announced. Each account type option was a selectable checkbox that responded correctly to screen reader activation. I found the account type I wanted, activated it, and located the "Continue" button using my screen reader's button filter function. So far, all was working well. However, this was about to change on the next page.
Table Troubles
The next screen requested that users select the specific account they want within a particular account type category. For example, if opening a credit card account, several options have varying interest rates and rewards perks. In my case, I was looking at checking accounts. There were five different checking account options, each with parameters and benefits. The website had possibilities organized in a table with five rows and three columns for visual organization. Each row was an account option, and the three columns were "Account Name," "Requirements and Benefits," and "Actions." The actions column included two buttons in each row, one labeled "Select" and the other marked "Learn More." At first glance, the design and structure seemed relatively simple and intuitive. However, I quickly became aware of a significant accessibility bug that made navigating the table's contents quite clunky and complicated.
As I moved through the table using manual navigation, my screen reader spoke the contents of an entire column before moving to the next column. In other words, the first five items my screen reader said in the table were the five account option names in the first and leftmost column. If working correctly, I should hear the contents of a row before the screen reader focus jumps to the next row. This defect made it extremely difficult to select an account option. I was interested in the third checking account listed in the table. Instead of pressing the tab key after hearing the account's description to move to the actions column, I would need to move past the other two account descriptions before reaching the actions column. At this point, I would have to remember that the third "Select" button in the column is the one that I needed to press for the third account option. This experience was a slow, clunky, and tedious account selection process. Despite it taking a very long time, I eventually made a choice and moved on to the next step. However, this behavior is detrimental to accessibility and, even more so, usability.
Address Annoyance
The following screens prompted users to enter personal information to determine eligibility for the account. All text fields were labeled correctly, and everything seemed fine until the site asked to enter a mailing address. The field was more modern, populating address suggestions as users input their addresses. In theory, this functionality simplifies the process because the user does not have to enter all their address parameters individually. As I typed, my screen reader said, "Choose From One Of The Options Below." However, no screen reader-detectable address listings were below the text field. I tried several times but with the same negative results. This experience is not the first time I have had accessibility trouble with these dynamic address fields. To my dismay, there was no way to enter the address manually and bypass the dynamic field. At this point, I had to abandon my mission or enlist the assistance of a sighted person. The most frustrating part was that it seemed like I was so close to completing my journey.
As I have shown, it only takes one significant accessibility defect to block screen reader users like myself from completing a given task. While problems like these are unacceptable on any website, they are particularly detrimental on banking sites because effective use of online banking systems is necessary for the personal and financial freedom and independence of individuals with disabilities. Those who manage the accessibility of banking sites must do whatever they can to ensure that all features and functionality are accessible to everyone.
Transitioning smoothly from my journey navigating an online banking website, let's explore some more accessibility challenges and helpful tips for digital banking.
3 Best Practices to improve the accessibility of your banking website
Besides the obstacles I've already discussed, there are more accessibility issues worth exploring. Let's dig into some specific instances, and I'll share three valuable practices.
-
Don't Forget About Accessible PDFs: Most banks offer digital statements in PDF form, which can be tricky for screen reader users like me. However, some banks are now providing accessible PDF options, making it much easier for us to review our statements.
-
Make Tab Navigation Smoother: Moving through recent transactions was frustrating for screen reader users, but improvements in tab navigation have made it much smoother. We can go through transactions more easily without getting stuck on each detail.
-
Improve Menu Navigation: While the homepage of banking sites is usually accessible, navigating through the account and settings menus has been a bit tricky. However, things are changing for the better, with banks making menus more straightforward to navigate for everyone.
These tips not only make online banking more accessible for people like me but also create a more welcoming experience for all customers.
And if you want to learn more about how financial services can be more accessible online, check out this whitepaper, Best Practices in Digital Accessibility for the Financial Services Industry.
Why Accessibility Matters for Customers on Financial Websites
In wrapping up, I hope my journey through online banking accessibility has shed light on the challenges many face and the progress being made. By sharing my experiences, I aim to inspire positive change in digital accessibility.
Remember, whether you manage a banking website or use one, we all play a role in creating a more inclusive online environment. By implementing accessible design practices and staying informed about accessibility tools and resources, we can make a real difference.
If you're involved in website development, I encourage you to test your site's accessibility.
Editors note: This is a post written by our marketing intern, Michael Taylor. This post reflects his opinions and experiences.
