During a web development project, I had an exchange with intern developers who asked me if “back-to-top” buttons on web pages should be made keyboard accessible, based on an article they found on the internet, which seemed to support the decision not to make it accessible. Unfortunately, I can’t find that article anymore, so I’m writing this one as a reminder.
The argument was that this type of button is the last element on the page, and only one tab away to get keyboard-only users back to the top of the page anyway, so it seemed repetitive.
You may not have heard of scroll-to-top, or back-to-top, buttons before, but if you are a web developer or a UI/UX professional you most likely have, and then you may think these kinds of buttons are petty or irrelevant. But if your website or app is scheduled for an Accessibility Audit, then they are relevant.
As a member of the International Association of Accessibility Professionals (IAAP), I often reach out to expert colleagues to discuss this kind of dilemma.
To me, it seemed obvious that it had to be accessible regardless of being repetitive. My concerns about not making it accessible are audits and legal aspects. But the interns did have a valid point supported by the argument in their referred article. So, I was curious to find out at least two things from my IAAP peers:
1. If somebody had come across this topic during an accessibility audit, and how they solved it.
2. If it could be perceived as discriminatory: to have the button available for some users and not for others.
I reached out to expert colleagues on the IAAP Forums. After posting my concerns and starting a thread, two experts got back to me.
Expert #1 said that although it could be perceived as a failure of WCAG Success Criteria 2.1.1, it may not necessarily have to be, as long as the page’s functionality is operable with a keyboard. He went on to explain that “as long as there is a way to perform that function, namely, to move the focus to the top of the page using the keyboard, then the button itself doesn’t necessarily have to be keyboard accessible.”
However, he warns that while some keyboard shortcuts, such as Home or CTRL+Home, do scroll the page back to the top; they don’t move the focus to the top. So, if the purpose of the back-to-top button is to get the focus back to the top, then in that case, “the functionality of the ‘back-to-top’ button isn’t available to me” from a keyboard-only user perspective.
“I always encourage you to make every clickable thing on the page keyboard focusable, even if you don’t think anyone needs it. But since you aren’t everyone, it might be hard to picture who might need that feature. For the person that needs it, they’ll be very happy you have it.”
Expert #2 echoed the WCAG failure aspect, saying that “not making it accessible would be a violation of keyboard-related accessibility standards,” which is audit relevant, but also highlighted that not making it accessible is the effect of a conscious choice, clarifying that “actively not making a button accessible when the default is to do so can be construed as an intentional discriminatory act.”
Expert #2 wrapped up by saying, “In general, making a button accessible is pretty trivial when done with the initial development.” Which made perfect sense, so I got back to the interns with that feedback, and we concluded the issue was very simple to fix and not worth leaving to chance.
