UnMasking Forms: Finding the Balance Between a11y and Security

For most companies and organizations, digital accessibility implementation is an uphill battle. While desire for inclusive design and customer satisfaction can be helpful motivators, reducing legal risk is often a primary driver. When adding cybersecurity into the mix, however, this can become a risk management battle, and one where cybersecurity usually wins—leaving accessibility and inclusive design behind.

In the US, there are a number of laws that protect individuals’ consumer, health, and other personally identifiable information. While laws and research-based standards can certainly help provide goalposts for achieving sufficient cybersecurity, they fall short when distinguishing between security theater and true cybersecurity. What are the real risks involved, and what is just for show?

According to a 2015 report from security firm Trend Micro, the top three breach methods used in the financial industry were device loss or theft, hacking or malware attacks, and insider threats. Device loss accounted for 41% of all breaches compared to the 25% caused by hacking and malware. Another security risk called keylogging involves the installation of malware on a person’s computer to capture the victim’s keystrokes. Malware can be packaged with free online software, disguised as a harmless program, or distributed by email as an attachment.

When dealing with form fields, however, many of the front-end security techniques focus on protection from shoulder surfing and targeted authentication hacking. But oftentimes, these techniques ignore the impact certain experiences have on disabled users. Keeping sensitive data protected is important for all users—including those who are disabled. However, accessibility and usability need to be considered in tandem with security concerns rather than as an afterthought.

When looking at common methods to achieve desired security measures for form fields, input masking comes up frequently as a way to protect from shoulder surfing and, when using encryption, from targeted attacks. For password fields, this can be achieved with type=”password”, but other techniques are used for masking other sensitive fields, including:

But how do these solutions measure up for users with disabilities? While progressive masking has been in HTML since the 1990s through type=”password”, several UX experts like Jakob Nielsen have called for an end to progressive masking as a default for sensitive fields, citing an increase of errors when unable to see the password, especially with heavier usage of mobile devices. Furthermore, with the increased uncertainty about typing passwords, users are more likely to store passwords in unsecure places like post-it notes in a desk drawer or in a .txt file on their computer, which contributes to security risk even more.

Progressive masking is one of the oldest methods of security from shoulder surfing and can work well for logins, but it can pose unique challenges for users with disabilities when trying to confirm accurate form entries. In particular, this can become an issue when trying to conform to WCAG 3.3.4 Error Prevention (Legal, Financial, Data), which requires that any web pages that cause legal commitments or financial transactions, modify or delete user-controllable data, or submit test responses are either reversible, checked for input errors (if possible) and the ability to correct input errors, or has a mechanism for reviewing, confirming, and correcting information before submission.

In the use case of a social security number field as part of a form that causes a legal commitment, progressive masking can become a blocker for WCAG 3.3.4 Error Prevention and pose an undue burden on those with cognitive disabilities and assistive technology users.

A more inclusive approach is to unmask the input only when it receives focus. On the surface, this approach seems to have the best of both worlds—masking the sensitive information for the majority of the form with the ability to review the characters when returning to the input. However, the inability to mask characters when submitting can be an increased security risk for users who rely on screen magnification software or increasing text or browser zoom in order to read web content.

That leaves us with one of the more popular methods of masking, which involves using a show/hide button. This is a popular pattern that is being used for password fields and other fields with sensitive data on web forms. More importantly, this technique puts the choice of showing or hiding sensitive information directly into the users’ hands. The standard show/hide pattern offers security through progressive masking as a default, yet conforms to WCAG 3.3.4 in its ability to reveal the input.

Outside of input masking, the security technique of disabling autocomplete can also cause accessibility issues. In fact, WCAG 1.3.5 Identify Input Purpose (AA-level) was added to WCAG 2.1 to address this particular issue, citing benefits to people with mobility impairments, language and memory-related disabilities, and those who employ assistive technology to add icons to input fields to communicate the input purpose graphically.

Unlike masking, this is a more difficult case to make given the security concerns. Research over the past three years has shown that autofill fields have not only been at risk from hackers but have also been exploited by web-tracking services to track which sites users visit and sell the information to advertising agencies. However, much like with input masking, it is less a case of accessibility vs. security and more about user choice. Autofill for forms is not obligatory, so users can choose whether or not they store data in browsers. In addition, with the prevalence of two-factor authentication, logins are less likely to be compromised even if a steal an account password.

In order to ensure accessible, secure, and accurate entry of sensitive data, we will propose a research-based solution that combines the show/hide input masking feature, allows autocomplete for form fields of sensitive data, and provides adequate labels, instructions, and error suggestion and prevention. However, we will also call for further innovation in the space and continued diligence in improving the accessible UX design for forms without sacrificing security