Accessibility Answers: Is Safari Better than Chrome for Accessibility?

Woman sitting and raising her hand beside another woman.

When I give presentations on accessibility, I usually 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 they help you understand accessibility better.

Is Safari better than Chrome for accessibility?

No.

That’s the short answer, but let’s go deeper. People often ask this type of question because Apple has developed a good reputation around inclusive design and accessibility. Maybe its browser has an edge? They also wonder what browser and screen reader combination work best together.

All valid questions, but in today’s “modern web” most browsers are comparable when it comes to accessibility features. If you’re testing your design or development work in a browser with a screen reader, you’ll want to stick to a few combinations:

  • VoiceOver with Safari on MacOS and iOS.
  • NVDA with Firefox.
  • Edge/Internet Explorer 11 with Jaws.
  • Talkback with Firefox or Chrome.

This post from Maxability on screen reader and browser combinations has more information. And if you want some survey data on screen reader usage, WebAIM has puts together some on a regular basis.

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

Image by rawpixel.

Accessibility Answers: How Do I Handle Alt Attributes

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 alt attributes?

Alt attributes can trip up even the most seasoned web worker. But do them right, and they make a huge difference to screen reader users.

I like this table from an article by Whitney Quesenbery.

If the image contains…The alt text should…
TextRepeat the text
Visual informationExplain it
Sensory informationDescribe it
Nothing newKeep it very short
(if you can’t make it “null”)

If you want more explanation, check out the W3C’s alt decision tree.

All images should have an alt attribute, even if it’s empty or null, like: alt="" .

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

Image by rawpixel.

Accessibility Answers: Which Accessibility Problems Do I Fix First?

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.

Which accessibility problems do I fix first?

You’ve tested your site or application for accessibility and discovered you have a long list of problems. You have a set of priorities dictated by other forces, like a feature list, a revenue stream or company goals. How do you fit in accessibility? Maybe you should tack it on at the end? Focus on it in a separate sprint?

You don’t have to do any of that, or alter your goals or priorities. Of course, you do have to slot accessibility into your workflow. That’s where you should start – wherever it fits into your workflow. In a perfect world, you want to be testing code for accessibility problems before it’s committed and pushed to production. You want to involve people with disabilities in your design thinking and testing. But one thing at a time here.

Fix the problems you have in your design or code in the next swath of work you already plan on doing. Pick one area and focus on it. Fix it, and deploy those changes, even if you don’t fix all the problems. Repeat that process. Accessibility is a continuum, not just one step.

That area of focus could be keyboard accessibility, adding missing labels or whatever your testing reveals. The problems you should fix first should be a small selection of ones you have in front of you. And that selection should be related to the work you’re doing already. Make it a little better one section at a time.

Further reading: You Don’t have Accessibility Problems, You have Quality Problems

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

Image by rawpixel.

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: onFocusonBluronSubmitonClick. 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.

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.