Your weekly frequent11y newsletter, brought to you by @ChrisBAshton:
A First Look at the Websites and Software Applications Accessibility Act Bill
The “Websites and Software Applications Accessibility Act” (or #A11yAct) has been put forward to the United States Congress. If it succeeds, it will build on the Americans with Disabilities Act (ADA).
Its aim is to lead to clearer regulations for digital accessibility requirements in the US. Here, Ben Myers looks at it from a web developer’s perspective. He opens with a disclaimer that he’s not a lawyer. For a legal perspective, read “Proposed web and software accessibility legislation introduced in United States Congress“.
Ben summarises the bottom line for us:
- Websites and apps will need to be accessible, period – no longer any need to demonstrate a link to a physical, bricks-and-mortar place (an idea called “nexus”).
- Regulations would be updated every three years.
- It’s not a silver bullet, but it will give disabled users more recourse against inaccessible products.
Ben then gives a short history of the ADA and why new legislation is necessary. One issue is the idea of ‘nexus’, and another is that it did not keep up with the times, but the main issue is ambiguity. The lack of published regulations means individual courts are left to interpret the act, leading to inconsistent outcomes in accessibility lawsuits.
Are you sure that’s a number input?
Kilian Valkhof highlights how <input type="number"> is often used incorrectly, despite it being available in browsers for around 8 years now.
Number inputs display a ‘spinbox’ (up and down buttons) to make it easier to increment or decrement the input. This kind of indicates the type of thing this input type should be used for: non-identifying numbers.
Instead, a lot of sites use number inputs for things like 2FA codes, social security numbers and credit card numbers. These are identifiers, where if you’re off by just 1 digit it’s much the same as being off in ALL the digits. Having a spinbox for this provides no value.
If your input is a set of digits that is used to identify someone or something, it’s not a number type, even if the input itself is entirely made of numbers. What you want in those cases is <input type="numeric">.
Perceived affordances and the functionality mismatch
Léonie Watson shares a design problem she encountered on Twitter. When you have ‘buttons’ grouped together in a row, and only one can be ‘active’ at any one time, how should it be marked up?
This fits quite nicely with a standard radio button form control, where you can only select one radio input. Choosing any other radio input automatically de-selects the previously chosen one. Exactly what we’re trying to achieve in this design problem.
However, whilst that might work well enough for sighted users who use a mouse, it creates a UX issue for keyboard users and screen reader users. This is because, whilst the inputs may look like buttons – which can be tabbed between – they are marked up as radio buttons, which require a different key input to navigate between the options. Once on a radio control, hitting ‘tab’ simply skips to the next interactable element after the radio control (with the exception of Firefox).
Léonie explains quite a bit about ‘affordance’: designing things in such a way that users can use their past experiences to already have a good idea about how something is supposed to work. She argues that whilst this concept works in the real world, it hasn’t translated to the digital world very well.
Lea Verou, the person who asked the original question on Twitter, ended up creating a custom component and accompanying article.
Did you know that you can subscribe to dai11y, week11y, fortnight11y or month11y updates! Every newsletter gets the same content; it is your choice to have short, regular emails or longer, less frequent ones. Curated with ♥ by developer @ChrisBAshton.
