When I order something online, usually from my phone, I have to enter different pieces of numerical information. If you use a mobile device, you’ve probably noticed that depending on what kind of information a form field requests, you’re sometimes presented with different on-screen keyboards.
Here is a side-by-side example for entering a credit card number:
Numbers keyboard
Standard keyboard
Which of these keyboards makes it easier to enter a credit card number? For most people, it’s going to be the numbers keyboard.
Reduces time on task: There’s no need to switch to the numerical view of the standard keyboard when the UI provides access to the numbers keyboard.
Lessens cognitive load: You’re presented with a telephone keypad which centers numerical inputs over letters or symbols.
Increases accuracy: The number keys are over three times the size of the standard keyboard which reduces entry errors.
Use the proper input type
Enabling the numbers keyboard for certain input types is a great usability improvement. But what about accessibility? We need to ensure we’re programmatically indicating what kind of numerical data the input requires and that we’re displaying the right version of the numbers keyboard as there are slight variations.
The HTML specification includes 21 input type attributes. One of the types is actually number but its intended use is for setting a value in a range rather than for just anything that might be numeric:
The input element represents a control for setting the element’s value to a string representing a number.
<label>How much do you want to charge? $<input type="number" min="0" step="0.01" name="price"></label>
We also need to keep in mind success criteria 1.3.5: Identify Input Purpose which requires setting autocomplete attributes to ease data entry. Let’s look at how to properly mark-up inputs for telephone number, zip code and credit card number.
Telephone number
Use input type="tel" to enable the numbers keyboard. With the autocomplete="tel" attribute included, we can see how iOS offers telephone number suggestions as well.
Since all postal codes are not numbers-only like US zip codes, use input type="text" and set the pattern attribute to enable the numbers keyboard. Include autocomplete="postal-code".
This example is for US zip code entry of 5 digits, 0-9.
Again, use input type="text" and include the pattern attribute for a 16-digit number. If you want to validate against different credit card types, use the appropriate regular expressions in your pattern attributes such as this one for Visa: ^4[0-9]{12}(?:[0-9]{3})?$
Other numerical types you might want to experiment with include date, month, time and range. Just don’t default to input type="tel" when the goal is to display the numbers keyboard.
I originally created Accessible Web as a sarcastic reaction to a developer changing his website to require users to disable JavaScript to use it. The reactions on Twitter were hilarious! So many angry developers didn’t get the joke that they do the same thing when they require users to have JavaScript enabled to do anything on their websites.
I decided to create something similar but with CSS. And with a message about semantic HTML. I’ve recreated the experience below.
Whew! That’s better. So guess what?
The web is inherently accessible
Your weekly reminder that the web is accessible by default and it’s our design decisions that stop it being accessible #a11y
Why did you have to disable CSS to view this website? No reason other than a design choice that excludes sighted people.
Did you know? This is how many visitors “view” webpages already:
Search engines
Bots
Site crawlers
Analytics
Blind people
This webpage is fully accessible to people with screen readers and Braille displays. But many websites are not due to poor design choices that exclude some people.
What is web accessibility?
When a page is accessible, it was developed with the intention of working for as many people with disabilities as possible. A good place to start learning is the W3C’s Introduction to Web Accessibility. Find out the different ways people with disabilities interact with the web.
Web Content Accessibility Guidelines (WCAG)
WCAG is a set of success criteria for determining if a page is accessible, led by four guiding principles:
Perceivable: Information and user interface components must be presentable to users in ways they can perceive.
Operable: User interface components and navigation must be operable.
Understandable: Information and the operation of the user interface must be understandable.
Robust: Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies.
These contain guidelines and a hierarchy of success criteria from Level A to Level AAA. Many accessibility laws, and current best practice, point to WCAG 2.1 Level AA compliance. There are 50 discrete success criteria to evaluate, though many are not applicable to all pages. For example, if a page doesn’t contain video, you don’t have to evaluate against success criteria for captions or audio descriptions.
Did you know? The WCAG guidelines were first published in 1999. Web accessibility is not a new concept but a lot of people are learning about it only now.
Semantics
So what’s the point? The point is to develop accessible pages from the bottom up, starting with semantic HTML. A whole lot of developers think they know HTML but are actually pretty sloppy about it. Many don’t think it matters if they use a link or a button, but it does. Every semantic mistake introduces accessibility issues into your code. If you’ve never really “learned” HTML, check out this beginner’s guide to writing good HTML.
By far, CSS color contrast issues are the most frequent accessibility issues I see, but the HTML ones are problematic too. Outlined below are the top HTML-related accessibility issues I encounter.
Headings
If you visually scan this page, you can quickly see how it is broken up into sections. That’s due to using headings or the h1-h6 elements. It’s important that every page have at least one h1 so people and search engines know what the topic of the page is. From there, cascade down to h2, h3, and so on.
Did you know? People using screen readers can navigate by headings in much the same way that sighted people can visually scan the page for items of importance.
Form labels
Every input needs a label. It’s really that simple. And best practice is to make that label visible. This helps people remember what information they’ve entered. Programmatically link each pair using the for attribute on the label matching the id attribute on the input.
This enables a couple things:
People can now click or tap on the label to give focus to the input. This is especially useful for checkboxes and radio buttons that often have small hit areas.
People using screen readers will now hear the label announced when the input is in focus.
<label for="like-cats">
<input type="checkbox" id="like-cats">Please confirm that you like cats</label>
Let people know when a field is required by adding the required attribute to inputs. Many modern browsers do cursory form field validation.
Buttons and links seem very similar to some developers but they have very different semantic uses. Buttons are used for controls on a page, such as a form submit or toggle, while links are used for navigation, literally for linking to another page. If you use them interchangeably, people can get confused about what a button or link is going to do when activated.
Some people try to make their own custom buttons instead of using the <button> element, which is already accessible:
<button> is keyboard focusable
<button> is activated with enter and space keys
Tables
There are many legitimate uses for tables on the web but they are often coded incorrectly. Much as an input needs its label, a table data cell needs its table header. This allows the applicable table header to be read by a screen reader before the table data cell contents. Additionally, each table needs a <caption> that provides a description of the table contents to people using assistive technologies
About My Cats
Cat’s name
Cat’s color
Luna
torbie
Stellan
black and white
Images
The one thing about accessibility most people know is that images need alt text. This may seem straightforward but let’s look at three examples.
1) Alt text matters
Semantically speaking, every image needs an alt="" attribute. This alone will pass an automated accessibility checker. If an image is purely decorative, you can even leave the alt value empty. But if an image provides context to the content, the alt text must accurately describe the content of the image for people who cannot see it. The alt text for the image below is two cats on an easy chair under a blanket.
2) SVG
SVG doesn’t support the alt attribute. Instead, add a <title>element inside the <svg> element with the alternative text description.
Add the role="img" attribute to the <svg> element to tell assistive technologies that it’s an image.
Add the aria-labelledby attribute to the <svg> element to name the image for assistive technology.
Any time you display complicated information, provide a robust description of the key points of the map or chart. All people will benefit from this for reference. No matter how you mark this up— using <figcaption> or just a <p> element—give that description a unique ID.
Add the aria-describedby="unique-id" attribute to the <img> element. This programmatically connects the image with the description for assistive technologies.
Remember to include the alt attribute with a short explanation of the image. Alt text for the image below is a cat sitting on a bed that is divided up into areas.
Cat bed, never used. Pillows show wake for food here and purring zone. Other areas on the bed are listed as grooming salon, sleeping area, launch pad to the bedside table, parlor, heaving spot, napping quarters, meditation area, stretching area, yoga studio, and good attack zone. A black cat sits happily in the middle of the bed.
A few days ago, after receiving yet another spam submission from the contact form on my portfolio website, I had an epiphany about how to implement a honeypot to block bots instead of a captcha (which nobody likes anyway). I posted about this on Twitter and user @markdeafmcquire asked how I did it.
I just figured out how to add a honeypot radio button to my contact form (PHP/HTML/CSS)
Captchas are those annoying puzzles you have to solve in order to prove you’re human. They are often inaccessible to people with disabilities and they can be difficult to figure out and pass.
Honeypots are passive, often implemented as hidden form fields that bots will fill out and humans won’t. If that hidden form field has a value, then you know the submission is from a bot and can be rejected.
My honeypot solution
My website uses PHP code with HTML to display the contact form as well as doing a server-side check on the form data when submitted.
The first thing I had to add was a hidden honeypot form field to trip up bots. I used a radio button.
Include the aria-hidden="true" attribute on the <label> element to hide the honeypot from assistive technologies
Use a CSS class to hide the <label> element from sighted users
Add style="display:none" to the <input> element, which prevents keyboard users from tabbing to the radio button
The second thing I had to add was a check in the PHP to determine if the radio button was selected when the form was submitted. I set the radio button to value="1" and the form check fails if the value of honeypot==1.
//check for honeypot
if ($_POST['honeypot'] == 1) {
$problem = TRUE;
}
Since it’s only been a few days, I don’t have enough data to determine if my solution is working well. I will update this post in the future.
Update December 2020
This solution has been working well for months now and I have not received any spam. Thanks to @AgenceCreatif on Twitter for trying out the code and offering feedback.
Accessible PHP honeypot form
Below is the PHP and HTML for adding an accessible contact form to your website, including the honeypot, and a way for people contacting you to send a copy of the email to themselves. Just update it with your email address.
