Accessibility as a Cyber Security Priority  ## Metadata - Author: [[ncsc.gov.uk]] - Full Title: Accessibility as a Cyber Security Priority - Category: #articles - Document Note: - #cybersecurity - #accessibility - #inclusivedesign Author: NCSC (UK National Cyber Security Centre) Source: Website Reference: https://www.ncsc.gov.uk/blog-post/accessibility-as-a-cyber-security-priority date created: 2025-08-22 00:00 # Title: Accessibility as a Cyber Security Priority ## Table of Contents: - 🔗 📝 Summary(#-📝-Summary) - 🔗 📖 Main Content(#-📖-Main-Content) - 🔗 🗒️ Notes(#-🗒️-Notes) - 🔗 📖 References(#-📖-References) - 🔗 🗣️ Paraphrase(#-🗣️-Paraphrase) - 🔗 📰 Newsletter(#-📰-Newsletter) - 🔗 ✅ Action Items(#-✅-Action-Items) - 🔗 🧪 Hypotheses(#-🧪-Hypotheses) - 🔗 📊 Methodology(#-📊-Methodology) - 🔗 ❓ Questions(#-❓-Questions) - 🔗 🔮 Future Research(#-🔮-Future-Research) - 🔗 💡 Implications(#-💡-Implications) - 🔗 🧠 Learning Styles Assessment(#-🧠-Learning-Styles-Assessment) - 🔗 📊 Accessibility Assessment(#-📊-Accessibility-Assessment) - 🔗 🌍 DEIB Assessment(#-🌍-DEIB-DEIB-Diversity-Equity-Inclusion-and-Belonging-Assessment) - 🔗 ✅ Logical validity(#-✅-Logical-validity) - 🔗 DARVO Analysis(#-🔍-DARVO-Analysis-Prompt) - 🔗 🔍 SEO Evaluation(#-🔍-SEO-Evaluation) - 🔗 🎯 Conclusion(#-🎯-Conclusion) ### References: - Thinks Insights & Strategy research on lived experiences of people with disabilities (commissioned by NCSC) - Microsoft Inclusive Design resources (Inclusive 101 guidebook) - Web Content Accessibility Guidelines (WCAG) ## 📝 Summary: The article argues that accessibility is essential to effective cyber security. Through “Anna’s” lived experience of vision impairment, it shows how inaccessible security measures—like timeouts, inaccessible MFA options, and non-inclusive training—create friction, increase human error, and drive insecure workarounds. It recommends embedding accessibility and usability into security requirements, collaborating with colleagues (including those with accessibility needs), and being flexible on the “how” of controls (e.g., offering multiple MFA options). The outcome is security that is more resilient, inclusive, and effective for everyone. ## 📖 Main Content: The article reframes accessibility from a compliance checkbox to a core security requirement. It highlights that 22% of working-age adults are disabled and that inaccessible security increases human-factor risk. Key problems include inaccessible training/policies, visual- or audio-only cues, color-dependent risk indicators, poor error feedback, and rigid controls that disable assistive technologies—each pushing users toward risky workarounds. The piece underscores that designing for disability often improves usability for all (permanent, temporary, situational barriers). Rather than treating people like patchable software via more training, organizations should address design flaws. Three practical approaches are offered: - Work closely with colleagues to understand needs and manage risk via sensible exemptions. - Maintain security goals but flex the methods (e.g., varied MFA mechanisms). - Make accessibility/usability first-class security requirements; ask vendors for accessibility statements and seek WCAG compliance but go beyond checklists. It concludes that incorporating accessibility strengthens human cyber risk management and expands the talent pool, while aligning with modern assurance and risk practices. ### 🗒️ Notes - Lived experience case: “Anna” (vision impairment) - Barriers: Face ID alignment; time-limited sessions; zoom leads to misclicks; stress escalates quickly. - Consequences: Errors, inability to complete secure tasks, pressure to bypass security. - Why accessibility matters in security - 22% of working-age adults are disabled; 4.9M disabled people in UK workforce. - Benefits: fewer errors, fewer workarounds, better outcomes, talent attraction/retention. - Risks if ignored: increased incidents, avoidance of secure processes, inequity. - Common accessibility failures in security - Non-accessible training/policy formats and language. - Complex UIs, mislabelled controls, ambiguous links, single-modality alerts. - Color-only risk signaling (red/green) excludes color-blind users. - Lack of clear feedback/error states; false sense of control configuration success. - Security breaking assistive tech; users delay updates fearing compatibility loss. - No accessible recovery paths/support turning near-misses into incidents. - Usability and security are interdependent - Human error rates remain high; accessibility helps mitigate human-factor risk. - Universal benefit of accessible design - Deaf colleague vs. ear infection vs. noisy environment: captions/transcripts help all. - Temporary and situational barriers mirror permanent disabilities. - Training ≠ fix for inaccessibility - Training only helps knowledge gaps; design gaps require design fixes (e.g., timeouts). - Three recommendations - Work with colleagues: co-design, gather feedback, test with users with access needs; risk-managed exemptions. - Don’t compromise the “what,” be flexible on the “how”: multiple accessible MFA options increase resilience. - Make accessibility/usability explicit security requirements: request vendor accessibility statements; seek WCAG alignment; avoid check-box compliance mentality. - Strategic shift - NCSC exploring new assurance practices and universal barriers framework adaptations. - Embracing accessibility improves human cyber risk management and inclusion. ## 📖 References: - NCSC blog: Accessibility as a cyber security priority - Thinks Insights & Strategy (lived experiences of people with disabilities in cyber contexts) - Microsoft Inclusive Design toolkit (Inclusive 101 guidebook) - WCAG guidelines (W3C) ## 🗣️ Paraphrase: 1) Original idea: We don’t intend to create hard-to-use security, but we do when we ignore accessibility or think usability must be sacrificed. Human error in incidents remains high; accessibility addresses human-factor risk by stress-testing controls under challenging conditions. Paraphrase: Security becomes difficult not by design but by neglecting accessibility or by falsely pitting usability against protection. Since many breaches cite human mistakes, baking accessibility into requirements is a practical way to confront human-factor exposure, ensuring controls still work when tasks are toughest for users. 2) Original idea: Training isn’t a cure-all. If Anna can’t meet short timeouts due to her disability, more training won’t help; inaccessible design forces bypasses. The fix is to make the control accessible. Paraphrase: Education solves knowledge gaps, not design barriers. When a control like a session timeout obstructs someone’s workflow because of disability, additional courses won’t change behavior; people will sidestep controls to get work done. The remedy is to redesign the security measure for accessibility. ## 📰 Newsletter: Learning web development meets human-centered security this week. We’re spotlighting how accessible design isn’t just kind—it’s a force multiplier for cyber resilience. From multi-factor authentication that offers choices (app, token, voice, passkeys) to captions and transcripts that help deaf colleagues and anyone in a noisy coffee shop, the lesson is clear: when security works for those with permanent, temporary, or situational barriers, it works better for everyone. What’s new: - Education corner: Build login flows with multiple accessible MFA options and descriptive error states. Bonus points for WCAG-aligned components and captioned how-to videos. - Community highlights: Teams co-designing with disabled contributors report fewer workarounds and smoother audits—accessibility reduces human-factor risk. - Plugin watch: Look for security plugins emphasizing accessibility statements, keyboard navigation, and ARIA labeling. If they don’t have it, ask for it. Quick links: - Microsoft’s Inclusive Design resources (search for “Inclusive 101 guidebook”) - WCAG overview at W3C for practical criteria - Passkeys 101 from platform vendors to diversify authentication Friendly reminder: training patches knowledge, not design. If your timeout locks folks out mid-task, rewrite the control—don’t just write another policy. Keep building safer, kinder web experiences. Your use - Summary: Accessibility is an important aspect of cyber security, as it ensures that individuals with disabilities or impairments are not excluded from using systems or technology. Failing to consider accessibility can lead to challenges and risks. The document highlights the experiences of individuals with disabilities in relation to cyber security and identifies various ways in which security measures can be inaccessible. It emphasizes the need to address accessibility in security decision-making processes and provides recommendations for making security more accessible, such as engaging with colleagues, being flexible in approach, and considering accessibility and usability as part of security requirements. Overall, prioritizing accessibility in cyber security can lead to more inclusive and effective security measures. - URL: https://www.ncsc.gov.uk/blog-post/accessibility-as-a-cyber-security-priority  3 years ago, Anna (not her real name) was diagnosed with a neurological autoimmune disease in which her body attacks substances that are naturally found in the body, causing pain and vision loss. Before her diagnosis, Anna worked in software technology and felt very confident and safe online. She now uses glasses, a magnifying glass and screen magnification where needed. Anna has no peripheral vision or depth perception. Face ID, or proving her identity by taking a photo of herself on her phone are impossible as she does not have the vision to line up her face with the camera. Trying to zoom in, clicking on the wrong link, or using websites with a time limit enhance her frustration and constantly remind her of interactions that used to be second nature, but now feel like an ongoing battle with technology. “I can start to get very stressed" says Anna. "The pressure can make me feel inadequate, which makes me shake. For me, it can spiral very quickly.” Anna’s experience is taken from [Thinks Insights and Strategy](https://thinksinsight.com/accessibility-and-cyber-security/), looking at the cyber security 'lived experiences' of people with disabilities. Commissioned by the NCSC, it's part of a growing body of work identifying how cyber security actions can be challenging if you have an accessibility requirement. Accessibility is about ensuring that nobody is excluded from using something due to a disability or impairment. It is about helping **everybody**, irrespective of any physical or neurological difference. An estimated [22% of working age adults are disabled, with 4.9 million disabled people in the workforce](https://www.gov.uk/government/statistics/the-employment-of-disabled-people-2022). There are many reasons to address accessibility, whether meeting legal requirements, delivering better operational outcomes, or attracting and retaining a more diverse set of talent. Addressing accessibility also provides cyber security benefits by making systems more usable and making human errors or workarounds less likely. Conversely, if we fail to consider accessibility, these risks increase. If Anna was working in **your** organisation, would she find your systems accessible? Where might your processes be challenging, and what could the security consequences be if doing things securely wasn’t accessible? #### How security can be inaccessible Anna might not work for your organisation, but if you have security measures that aren't accessible, then the system will be harder for **everyone** to use. Security measures can be inaccessible in a number of ways. Here are a few examples: * Awareness campaigns, training, or security policies that are not in accessible formats or written in simple, accessible language leave people lacking the knowledge they need of how to do their jobs securely. * Complicated interfaces, mis-labelled buttons, ambiguous link text, or audio-only/visual-only warnings make human errors more likely. * Colour schemes of 'red for high risk' and 'green for safe' may be inappropriate for people with colour blindness. * A lack of accessible feedback or error messaging when completing a configuration change may lead to falsely presuming you have implemented a security control when you haven’t. * Security that removes accessibility functionality might leave people needing to adopt a less-secure workaround or avoiding doing their job entirely. * Concerns about breaking compatibility with assistive technology or altering coping strategies might prevent users updating systems. * If accessible ways to recover from errors or access support are not present then what could have been a 'near miss' can quickly turn into a serious incident. The examples above are not exhaustive, but they highlight how accessibility is important for processes as well as technology. We don’t intentionally end up with security that is hard to use. We often end up with it because we don’t factor it in to our security decision making, or because it's seen as someone else's responsibility. Alternatively it can be seen as necessary to compromise usability to achieve security, not recognising the two to be interdependent. This is surprising given the number of incidents which still claim 'human error' as a contributing factor. Considering accessibility within your security requirements is a great way of ensuring that you are actively considering your 'human factors risks', and that you are stress testing your security against the conditions where people will find it most difficult to use, and where human errors will be most likely. #### Security that works better for everyone Everyone benefits when systems are deployed where accessibility is built-in. Consider three colleagues: * one is deaf * one has an ear infection * one is working in a noisy environment without access to headphones If your security awareness video doesn’t have a transcript or captions, it isn’t accessible to *any* of them. By focussing on meeting the accessibility needs of your deaf colleague, you make the solution work better for *everyone*. This is an example of how the barriers people experience can be permanent, temporary and situational. [Microsoft's inclusive 101 guidebook](https://inclusive.microsoft.design/) (part of a set of tools on inclusive design) has further examples of this for a range of disabilities. In all cases, designing for people with disabilities makes things more usable for everyone. We all experience limitations based on our environment that mean that security doesn’t work for us in the way it was designed to. However, if that security has been designed with accessibility in mind, it will be more resilient to work as it’s really done, and less likely to fail. #### Training is not a silver bullet When people behave insecurely, the temptation is to treat them like we treat technology. We 'patch' them by sending them on a training course, in the hope that this will fix the 'vulnerability' in the system. Training is only effective when the problem is a lack of knowledge. However if the problem is a lack of accessibility, training isn’t the answer. If the security timeout is too short for Anna to complete her job due to her disability, no amount of security training is going to solve that. People will bypass security to do their jobs if you make them. The security itself needs to be made more accessible. #### What can you do? #### 1. Work with your colleagues The best way to make security more accessible is to engage with the people who interact with it. Consult your colleagues in your security decision making processes and encourage feedback. Test new systems and processes with people with accessibility needs to discover where issues might exist. You don’t need everyone in your security team to be an expert in accessibility. People with accessibility requirements themselves, accessibility professionals, user researchers, user experience (UX) designers, service owners or developers all likely have knowledge you could be using if you make security a team sport. If colleagues need access to specific functionality or technology that might otherwise break security policies, work with them to understand their needs and manage the risks. Where it isn't appropriate to change a whole policy, have a process to enable people to raise issues. Working collaboratively to make sensible exemptions and managing any associated risk is better than forcing people to avoid security, or suffering through not being comfortable enough to raise a concern. #### 2. Don’t compromise on the 'what', but be flexible on the 'how' You don’t need to dilute your security requirements to achieve accessibility, but you should be open to different ways of realising these requirements. For example, imagine you've identified an asset that requires multi-factor authentication (MFA). There is no 'universally accessible' MFA method. One person's preferred method might be a barrier for another. The key here is to [offer enough flexibility that people can select an approach that works for them and their needs](https://www.ncsc.gov.uk/guidance/authentication-methods-choosing-the-right-type). Providing this flexibility has a secondary benefit in that in improves the resilience of your systems. So if one method of authentication were to fail, an alternative method can provide a backup to minimise business loss. #### 3. Make 'accessibility' and 'usability' part of your security requirements Treating usability and accessibility alongside other security requirements rather than a separate thing is useful to ensure it gets considered. Take time to consider which actions would have the largest impact if they were carried out insecurely or avoided, and then test the accessibility of these. You can conduct some due diligence by asking vendors or suppliers for an accessibility statement for their products which should let you know where any shortcomings might be. Alternatively, you could build in a requirement for a certain level of compliance against a framework or standard such as the [Web Content Accessibility Guidelines (WCAG)](https://www.w3.org/TR/WCAG21/). Just be mindful that, as with security more generally, you need more than compliance for effective risk management. #### Striving for more inclusive and effective cyber security With new research, our understanding of the barriers people face interacting with systems and the implications for our shared security goals is improving. This understanding is providing the motivation for citing the importance of usability and accessibility in our guidance and for including it as a requirement as we transform the way we do assurance. It is driving us to trial new approaches to the identification and treatment of cyber risk, and to explore wider barriers to successfully implementing security through adapting the [universal barriers framework](https://gds.blog.gov.uk/2019/03/26/understanding-all-the-barriers-service-users-might-face/) for the design of security. Recognising and responding to the increased drive to consider accessibility as a security need will help organisations get on top of their human cyber risk, while also cultivating a more inclusive culture and allowing themselves to make the most of a more diverse talent pool. ###### Lee CNCSC Sociotechnical and Risk Group  , Accessibility as a Cyber Security Priority, ncsc.gov.uk, 01h8y8tk58m087fppz265a7rhe.