Cybersecurity Awareness Month: where security and accessibility meet

October is Cybersecurity Awareness Month, and this year the National Cybersecurity Alliance chose a theme we can get behind: “Don’t Make It Easy for Them.” The idea is that small habits, repeated every day, make you a harder target for attackers.

We’d add one thing. While you make life hard for attackers, don’t make it hard for your users. A login page that a screen reader user can’t get through keeps out a lot more than attackers. And a security program that leaves part of your team behind has a gap in it.

Here’s where security and accessibility meet: your login and verification flows, your security training, the third-party code running on your site, and how we protect your data at Accessible Web.

Security features that lock out real users

The features you added to keep bad actors out are often the same ones that keep users with disabilities out. Check your login, sign-up, and checkout flows for these:

• Image CAPTCHAs that ask you to click every traffic light are impossible for blind users. If you use a CAPTCHA, Web Content Accessibility Guidelines (WCAG) success criterion 1.1.1 asks for a text alternative that describes its purpose and a version that works through a different sense, such as audio.
• Login forms that block pasting or password managers turn signing in into a memory test. Accessible Authentication (Minimum), criterion 3.3.8 in WCAG 2.2, asks you to support copy and paste or password managers instead.
• One-time verification codes that expire in seconds. Someone using a screen magnifier or a switch device may need more time to move a code from their phone into a form. Timing Adjustable (2.2.1) asks you to let users turn off, adjust, or extend time limits, with a few exceptions.
• Session timeouts with no warning, which fall under the same criterion. Tell people before their session ends and give them a simple way to ask for more time.

Here’s the encouraging part. The options security teams already recommend, like password managers and passkeys, also remove the memory test from logging in. You don’t have to pick between a secure login and an accessible one.

Want the details on each criterion? Browse the Accessible Web WCAG 2.2 Knowledge Base.

Is your security training accessible to your whole team?

Your employees are part of your security program, so your training has to reach all of them. A lot of it doesn’t. Warning banners flag suspicious emails with color alone. Training videos go out without captions, and the quiz at the end only works if you can click and drag.

If an employee can’t complete the training, they don’t get the lesson, and your organization carries that risk. A few places to start:

• Give keyboard and screen reader users their own version of each tip, like how to read a link’s destination without hovering.
• Caption every training video and provide a transcript.
• Ask your training vendor for a VPAT (Voluntary Product Accessibility Template) before you renew.

Building accessibility skills across your team pays off here too. Accessible Web Academy offers self-guided courses for designers, developers, content creators, and the other roles that make up your organization.

Accessibility overlays and the code you didn’t write

An accessibility overlay is a widget you add to your site with a line of JavaScript. It promises to make your site accessible automatically. We’ve written about why that promise doesn’t hold up: overlays tend to conceal barriers rather than remove them, leaving users with disabilities with a frustrating second-class experience.

Cybersecurity Awareness Month is a good time to look at the other cost. Every third-party script you load runs on your pages with the same access as your own code. You’re trusting whoever controls that script, every time it loads.

That trust can go wrong. In 2024, the domain behind Polyfill.io, a popular JavaScript service, changed hands, and researchers found it injecting malicious code into more than 100,000 websites that loaded it. Visitors were redirected to scam sites. The site owners hadn’t changed a thing. 

Any script you add, an overlay included, belongs on the list you review. Ask what it does, who maintains it, and whether you need it at all. For accessibility, you don’t. Real accessibility lives in your own code, which your team controls. Here’s why we’re not an accessibility overlay and what we do instead.

How we protect your data at Accessible Web

We just asked you to look hard at every tool on your site. It’s fair for you to ask the same of us.

Accessible Web completed a SOC 2 (System and Organization Controls) audit, an independent third-party review of the controls we use to protect your data. You can read our SOC 2 announcement for details.

Our Trust Center shows our security practices and documents in one place. If your procurement or IT team needs documentation before approving a new vendor, send them there. 

Start with the pages that let people in

Pick the flows your users can’t avoid: sign-up, login, password reset, and checkout. Test those first, then give your team a way to keep them working. Accessible Web RAMP brings that whole process into one place:

• Automated Scanning and Recommended Tasks: Monitor your entire digital property on a schedule and receive a prioritized list of issues organized by frequency and impact to tackle first.
• Guided Manual Audit Tool: Walks you through every WCAG 2.2 AA success criterion, including the authentication and timing checks a scan can’t judge for you.
• Accessible Web Helper Chrome extension: Check a login page right from your browser.
• Remediation Tasks and Remediation Instructions: Turn what you find into assigned work, with pre-written guidance on fixing each issue.
• Accessibility Log: Keep and showcase a record of the work your team has done over time.

Try Accessible Web RAMP free for 14 days, or book a demo to see how it fits your team.

Cybersecurity Awareness Month wraps up October 31. Both kinds of work keep going all year, and we’ve got your back.