By: Mike Lehr, Human Resources and Sales Consultant
Banks must make their websites accessible to individuals with disabilities. That is how federal courts have interpreted the Americans with Disabilities Act (ADA). We have found five key tips go a long way to doing that. Ironically, software scans measuring accessibility don’t do this successfully.
That’s a key, key lesson: do not rely on scanning software to determine whether your site is accessible. Again, do not rely on this software for determining accessibility. In our audits and discussions with attorneys who have defended clients in lawsuits, these results are almost useless. What holds up best is the testimony and tests of sight-impaired users (SIUs) who have used the website. Nothing compares to observing a SIU running through a site. That’s because the WCAG 2.1 and Section 508 guidelines – used as the basis for compliance – have many interpretive elements to them. Yes, some we can quantify and code. About half we can’t. Images make the simplest examples. Scans state whether an alt-text exists. They can’t tell though whether the alt-text is necessary or even useful.
This doesn’t mean scans don’t help. They do. They look at the entire site. A human audit is just that, an audit, meaning it looks at a sample. Scans give one input to developing the site’s audit plan.
The Five Tips
We can summarize the five tips that go a long way to ensuring a site’s accessibility as easy navigation, useful alt-tags, and proper coding practices. The tips focus on SIUs rather than other disabilities because not seeing the site – or seeing it well – is the most difficult challenge to overcome even with good hardware.
1. Navigation Menu – Only One
Websites have many ways to navigate them. In addition to the traditional horizontal menu, mobile menus (hamburger menus) also exist. Sites also employ vertical menus on the left and right sides of the page. They also use fly-in menus that come in on certain pages. The tip refers to silencing all but the most comprehensive or dominant menu.
That means the site should be coded to do this when it detects a screen reader (SRs ̶ software that allows a SIU to read a site). It should be the most comprehensive and dominant menu. Remember, SIUs can’t see the screen well. They only hear it. Most times they won’t even know how big the window is on the screen.
Yet, SIUs often program SRs to prioritize links. That means SRs will read all menus. For the SIU, that becomes confusing as to which link to click. They hear too many duplicates. Imagine now going to a site where you see double of everything.
2. Alt-tags as Signposts
As mentioned above, SRs often prioritize links. That includes non-menu links such as those imbedded in text, images, and other elements. Links tend to take users to one of four places: another page, another place on the same page, another site, or a file such as a PDF. In doing so, one of two things happen: the user remains in the same window or opens a new one.
This tip refers to using alt-tags as signposts. Two sides of this exist. The first involves telling SIUs where they are going. Otherwise, they primarily think they go to another page. The site needs to tell them even if the image’s caption or surrounding text clearly states this. That’s because SIUs can program the SR to read only the links on a page, meaning the SR won’t read context clues.
The other side of this involves making each link distinct. For instance, “click here” often appears after descriptive text such as, “To go to our checking account page click here.” It tells SIUs nothing when they program the SR to read links only. This compounds if many links say “click here.” So, choose to make the whole phrase a link or add more description to the alt-tag.
3. Alt-tags as Additional Descriptors
Many misread the guidelines when they come to alt-tags for non-links such as images. They think it says – and scanning software reinforces this – that alt-tags can’t be blank. So, sites duplicate the caption in the alt-tag or add text to a purely aesthetic design element such as a color block, shape, or filler that communicates nothing.
Imagine a great, beautiful well-designed home. However, when you enter there’s clutter everywhere. You have to move things around. You even trip over some. This is “death by a thousand cuts.” Sites do the same to SIUs when they have duplicate, nonsensical, and useless alt-tags.
In such cases, code the alt-tag with the left double quotes followed by the right double quotes (“”). This tells the SR to skip the alt-tag and tells the scanning software an alt-tag exists (so it won’t flag it as an issue).
4. H-tags and TITLE Attributes
SRs assume sites use generally accepted coding practices. That means SRs will have problems with sites that don’t. Two of the more common ones that sites overlook are the h-tag and the TITLE attribute. The first identifies headers. The second identifies the page.
Sites can prioritize headers. Headers using an h1 tag is the most important. H2 tags are second, h3 third and so on. Most web managers know these headers as ways to change the look of a header. Their use can automatically enlarge, bold, italicize, color, or underline headers.
While h-tags allow designers to quickly add design enhancements to headers, they also serve to prioritize content. In this role, they help SIUs much. Just as SIUs can program SRs to read only the links on a page, they can also have them read just the headers. Some even allow them to program what level header to read, such as “read h1 – h3 headers” only. This means that headers must accurately reflect the relative importance of the website page’s content.
Unfortunately, content managers often only look at h-tags as design elements. So, rather than code a header using an h-tag, it might be quicker and easier just to bold and color text. After all, it will just look the same. However, this just relegates a header to common text. SRs will miss it.
TITLE attributes serve no real purpose for non-SIUs. Since they appear at the top of a page’s code, they can serve to further describe the page and reassure SIUs that they arrived on the page they wanted. Again, many sites just throw something similar to the page’s visible title in this or something abbreviated. More description often helps SIUs.
5. Help Desk Phone Number
Companies increasingly employ more automated forms of problem resolution. So, they aren’t likely to list a phone number prominently on their sites. Yet, such a number can go a long way to helping SIUs work through a site. Including the phone number near the top in the page’s coding will make it invisible to non-SIUs but accessible to SIUs with their SRs.
For instance, the site could include the number (along with times of availability) in the alt-text of the company’s logo in the upper left which often includes a link to the home page. Sites often include this number before or after input elements such as account logins.
Of course, this does necessitate that the bank supports the number. That might mean changing voicemail prompts and other protocols if the number has other uses. It also means training staff to handle such calls with sensitivity and patience.
Going a Long Way
Except for the first tip regarding menus, a reasonably experienced website content manager can perform these tasks. Even then, with less than an hour’s training, others can learn. Time and discipline remain the real challenge. It can begin though with ensuring that any new content incorporates these tips.
As for policy decisions, we recommend that banks purchase scanning and screen reading software. They make a world of difference. Also, and finally, we encourage banks to contact their local society for the sight impaired and ask for their help. Most members already have SRs. See if you can observe them using your site. It’s not only good community outreach, but I guarantee you will find it an eye-opening experience. We did.
For more information on this article and how Young & Associates can assist your bank in this area, contact Dave Reno, Director – Lending and Business Development at [email protected] and 330.422.3445.
