Accessible custom styled form elements

HTML elements like check buttons, radio buttons or select options can be hard to style with CSS in a custom design. There are many workarounds for this, but are he accessible?

The challenge

HTML elements like check buttons, radio buttons or select options can be hard to style with CSS in a custom design. There are many workarounds for this, based on two different approaches:

  1. Hide the form elements from sight and apply the styling on a container or related element
  2. Hide the form elements from sight and rewrite the functionality, using styleable elements like <div>s and JavaScript

The tests that these constructions need to pass is:

  • is the label attached to the input field with a proper for/id construction
  • can the selection be made with keyboard only
  • does a screen reader give feedback on the choice made

1: Apply the styling on a container

Some examples of styling form elements using containers or related elements. Not all are fully accessible, but can be adjusted to be.

Styled select box
Browser default for select options

 

For select drop downs:

For check boxes and radio buttons:

Advantage: the native HTML stays the same, so it’s accessible and works for every device.
Disadvantage for select options: the options are not styled, only the select box.

2: Use styleable elements like divs and JavaScript

Example Select2The most used library for restyling select boxes is Select2, build on jQuery. Other frameworks are Project Clarity, build on Angular .

Combobo and and Cauldro (the Dequelab pattern library) aim to be accessible for keyboard and screen reader.

WooCommerce recently created a fork of Select2, SelectWoo, with some accessibility improvements.

Advantage: All elements can be styled exactly as the designer wants
Disadvantage: all functionality has to be added with JavaScript to replace the native HTML behavior.

Accessibility concerns

Select2 is not accessible for screen reader users. They get no feedback on the suggestions and selections. The WordPress Accessibility team did a complete review and since then nothing much happened to improve this. I’ve tested Project Clarity and that is not accessible too.

I did some testing on SelectWoo and it works for keyboard and in Apple VoiceOver there is feedback announced. This also needs testing with other screen readers and voice recognition software. The examples with Ajax don’t have a no-javascript fallback.

Cauldron claims to be accessible. And my initial test prove it gives decent screen reader feedback and works with keyboard. But the HTML is very complex and we need to introduce a new JavaScript framework for this. Also the GitHub repo has open issues that get not much response from the authors.

Most assistive technology like screen readers and voice recognition software depend on semantic HTML. An element should be used for what it is intended. Replacing for example a select with <div>s means you also have to add all the functionality with JavaScript that natively comes with the semantic elements.

Using native functionality always is a guarantee to work on every device and is also not JavaScript depended on it to work well.

The first technique (apply the styling on a container) is accessible for all devices because it only uses extra CSS and doesn’t touch the semantics. All the functionality is already there and default handled by the browser.

It is impossible to style select option. But is that really necessary? Is it worth abandoning the native browser behavior for a complete rewrite in JavaScript of the functionality?

The days that a website must be pixel perfect and must look the same in every browser are over. There are so many devices these days, that an identical design for all is not doable. Or we must take a huge effort for custom form elements design.

Progressive enhancement

When a web page is loaded into a browser, the content (HTML) shows first, then the styling (CSS) and the JavaScript loads last. If a visitor has a slow connection, this means that the content must make sense, also without the CSS and JavaScript.

Using semantic, native elements for forms, makes sure that a visitor doesn’t have to wait until all the JavaScript is loaded before she can use forms like search.

Recommendations

As we aim to build accessible and for the future, robust and sustainable, let’s use the right element for the job and not rewrite already existing functionality in JavaScript that needs also a lot of ARIA to make it work for a screen reader.

So for select: only style in select box using CSS and let the display of the drop down options to the browser.  Sam Miller created a Codepen as basic example.

Workshop accessible content

How do you create content that can be understood by everyone, also for people that use the web in another way than you would expect? Keeping your content accessible isn’t hard. You just need to look at your text differently.

In this workshop, we’ll tell you what is important to keep your content accessible and also why. Have you ever ‘listened’ to your own website, how accessible is your content? We will talk about headings, images, links, video and audio.

Did you know Google is blind and deaf? Everything you do for accessibility is also good for SEO!

Introduction

Web accessibility is the degree to which a website is usable by as many people as possible.

We don’t all use the web always the same way. When adding responsive design we create a site accessible on desktop with different browsers and screen sizes, and also for different kind of mobile devices used with a mouse or touch.

We don’t always use the web the same way or in optimal circumstances. For example: reading on a smartphone in the sun in a noise environment is different than reading on a desktop in a quiet office.

In the future there will be even more options and technology, as we use the web not exclusively in our office or at home anymore. Not only people with a disability, but everyone that has an online connection will benefit from a robust and accessible website.

Change your point of view!
Don’t depend on how the website looks, but how the content is structured.

Content of the workshop

Have you ever listened to your website?

Try it yourself with Apple VoiceOver:

Under the hood

Have you ever looked under the hood of a website? Look at your site without style (CSS): this is also what Google depends on.

Reading level

Keep the reading level: 12 years old maximum.
Why? When you write at a high reading level, you expect that the reader it her best when she reads this. Maybe the reader is tired, hungover, in a car, distracted by the TV or annoyed by a nagging child.

Good reads:

Readability test tools:

Readability

  • Make text easy to skim and read. People don’t read on the internet, they
  • Skim for keywords and only read the part they are interested in.
  • Short summary at the top (TL;DR)
  • Divide the text in short paragraphs, use meaningful headings
  • No large blocks of text
  • UPPERCASE font is harder to read when you are dyslexic, only use if for
  • Short text
  • 16 pixels minimum is best for most devices
  • Keep it clean, restful

Headings

  • One H1 per page that tells what the page is about, the rest meaningful
  • A heading should be followed by the content it describes
  • Do not skip a heading level

Good reads about headings:

Heading test tools:

Link text

  • Use meaningful text
  • Avoid “click here”, “read more”, ”download”, ‘continue reading”. It’s meaningless and people have to read around the link to see what’s it about
  • If you use an image as link, use the alt text as link text

Images

  • Check if an image has a proper alternative text
  • If an image is purely decorative: leave alternative text empty (use alt=””)
  • If an image has meaning: give a short describing alternative text, don’t use this as spamming tool, keep it to the point
  • Don’t use “image of” in the alt text. A screen reader already announces the image as image
  • If the image is a chart or an infographic, add an alternative in content, on the same page or on a different page and and link that

Video

Use Subtitles: not only useful for deaf people, but also for example when useful you are in the train and forgot your headset, your native language differs, there is much background noise and you can’t hear it well.

Do not autoplay: screen reader users can’t hear their software speaking. Your spouse will wake up if you forgot to turn off the sound when you work in bed.

Audio

Transcript the text, write it out. Provide a link to that text below the audio track and do not autoplay (same as video)

Alternative text, subtitles and transcriptions are content Google can read. So this is valuable content to add for SEO.

New Zealand All Blacks perform their Haka, with subtitles. Did you know what they were saying? Subtitles can give a complete different perspective.

Accessibility in the Age of the Headless CMS

 Intro

A few months ago I asked in the Human Made general Slack channel: “What shall I talk about at WordCamp Europe?”
And the honourable Ant Miller replied: “Accessibility in the age of the headless CMS.”

React logoGreat, I thought. A new subject, much to learn and tell about, I started to read up on the subject. And then I realised: oh no, I have to learn React!

Continue reading “Accessibility in the Age of the Headless CMS”

WordPress, state of the Accessibility 2016

How accessible is WordPress now (2016), which improvements were made in the last years and what still needs to be done? Where can you find help and documentation to improve your code? What are the new Accessibility Standards, added to the WordPress Coding Standards?

How accessible is WordPress now, which improvements were made in the last years and what still needs to be done? Where can you find help and documentation to improve your code? What are the new Accessibility Standards, added to the WordPress Coding Standards?

This post is written for my presentation at WordCamp Europe 2016 in Vienna. You can find the Slides at Slideshare and the video on WordPress.tv. Continue reading “WordPress, state of the Accessibility 2016”

Workshop Keyboard Navigation

Short workshop on how to navigate a website with a keyboard only.

The basics

  • Tab: Move forward from link to link or to controls
  • Shift + Tab: Move backward from link to link or to controls
  • Enter: Activate links, buttons, or other interactive elements
  • Arrow: Navigate radio buttons and select boxes and scroll up and down a page
  • Spacebar: Activate radio buttons and check boxes and buttons

Continue reading “Workshop Keyboard Navigation”