Tag Archives: Front End Development

Accessibility Answers: How Do I Handle JavaScript and Accessibility

Woman sitting and raising her hand beside another woman.

When I give presentations on accessibility, I often get one or two questions I’ve fielded before. I’ve collected a handful for an ongoing series of posts with my answers. I hope it helps you understand accessibility better.

How do I handle javascript and accessibility?

Like everything else. It’s that easy. You can follow the same accessibility principles, making your web pages or applications perceivable, operable, understandable and robust. JavaScript changes nothing in that regard. Accessibility and JavaScript get a bad reputation because of some misconceptions. First, most people who use screen readers typically have JavaScript enabled, not the other way around. Also, all modern accessibility guidelines allow you to require JavaScript, so long as the scripted content works within the guidelines. WCAG 1.0 required interfaces to work properly without scripting enabled, but this isn’t the case anymore.

Further reading: Accessible JavaScript.

That said, you should keep these things in mind:

  • Use semantic HTML as your base. Employ native controls that work well with all devices, like <a>, <button> or <input>.
  • Follow progressive enhancement, and use JavaScript to aid in the functionality of your interfaces. Whenever possible, try to make your interfaces work at a basic level minus JavaScript. Think of it like that old, beat-up car that just never quits, no matter the conditions. We all appreciate cars like that.
  • Use device dependent event handlers: onFocus, onBlur, onSubmit, onClick. These will work with a variety of devices and input methods.
  • Implement ARIA where applicable to communicate context, like change of state, to assistive technology.

Further reading: Modern Web Accessibility with JavaScript & WAI-ARIA.

Further reading: Practical ARIA Examples.

Further watching: A Web for Everybody.

Follow the series Accessibility Answers. Ask me a question via my contact form or Twiter.

Image by rawpixel.

News for Betty + Accessibility Hackathon

Today, I participated in an accessibility hackathon run by White House Office of Science and Technology Policy, 18F, the National Institute on Disability, Independent Living, and Rehabilitation Research, and DC Legal Hackers. The day was packed with demos, discussion and coding on all sorts of projects, ranging from solving the lack of alt attributes on Twitter images to a more efficient way to integrate Section 508 into the government procurement process.

We didn’t solve everything in one day, but we had lots of ideas, worked together and did it in the open. I contributed to a new, in-progress web app called News for Betty. It’s a news aggregator that takes the home pages of major news sources and cuts out the cruft, making it easier for people of all abilities get to the news faster. A fun project for a former journalist! You can check it out on Github. A handful of my pull requests centered on improving its accessibility have already been merged.

It’s easy to jump into any problem thinking you need to bring a new solution. With a newer, but established project like News for Betty, the creators had already formed a solid base to an existing problem. Sometimes you just need to give something support, a nudge in a new direction or a different way of thinking, and maybe a few pull requests. 🙂

This is especially true on the Web where thousands of worthy projects need more accessibility attention. What have you helped today?

Accessibility Answers: What Can I Do Now for Better Accessibility?

Woman sitting and raising her hand beside another woman.

When I give presentations on accessibility, I often get one or two questions I’ve fielded before. I’ve collected a handful for an ongoing series of posts with my answers. I hope it helps you understand accessibility better.

If I could do a few basic things in my projects right now, what should they be?

Start simple. Focus on ensuring users can navigate your site using the keyboard. Make sure you have :focus styles where appropriate, and that each style has a reasonable contrast.

Further reading: Building a Strong Foundation with Keyboard Accessibility.

Next, make sure each control follows web standards. What do I mean by that? Items that behave like links, buttons and form fields should be just that: <a>, <button> or <input>. Don’t make your own interface elements from scratch. Use native elements, which come with accessibility features built in, and enhance from there.

Further reading: Links Are Not Buttons; Neither Are DIVs and SPANs.

Lastly, provide a <label> element for each form field in your code. Labels allow screen reader users to know what a field is meant to do or what that field needs in order to move on in an interface. Don’t make it harder.

Further reading: Accessible Form Controls and Placeholder Attribute is Not a Label.

Follow the series Accessibility Answers. Ask me a question via my contact form or Twiter.

Image by rawpixel.