Two interesting reads: Faruk Ateş on how Flipboard chose form Over function for their web version. Plus, Steve Faulkner weighs in with one approach that could make the content in the canvas available to all users.
Karl Groves on how you don’t have accessibility problems, you have quality problems.
Bruce Lawson writes a post on the accessibility of web components, again, going into the accessibility advantage and the messaging around the new technology.
A few weeks ago, a talented designer/developer colleague of mine at Automattic asked me about starting to use a screen reader to test for accessibility. I cringed a little.
Why? Because I remembered how daunting it was to learn how to use a screen reader. You turn it on, and you’re thrust into a new world. One that says things to you non-stop. 🙂 But in all seriousness, anyone can learn to use a screen reader for basic accessibility testing. You just need to recognize it has a learning curve, like anything else. Below, I share some tips I wish I knew when I started to integrate screen readers into my every day workflow.
Grab Your Flavor
WebAim has some fantastic information on screen readers and tutorials to help get you started.
- Using JAWS to Evaluate Web Accessibility
- Using NVDA to Evaluate Web Accessibility
- Using VoiceOver to Evaluate Web Accessibility
- Testing with Screen Readers: Questions and Answers
This isn’t an exhaustive list if screen readers, just the ones WebAIM has tutorials on. I use VoiceOver because I do all my development on a Mac. But I occasionally hop over to a Widows machine with NVDA.
You won’t learn how to test effectively with a screen reader the first day. Or the first week. Or the first month. Be patient. Practice. I like to think of it like distance running – you have to build up your distance base first. Once you have the base you can start to go places, and faster.
One mistake I made in the beginning was jumping into complicated web pages. If you have sophisticated interactions happening on the page, it’s hard to keep track of what’s happening there and what’s happening in the screen reader. So start with a sample page you’ve created with basic HTML and various elements. Put the standbys in place like links, buttons, form fields and such. Now, you can get an idea of what a screen reader does with standard elements.
You might be tempted to turn off your monitor, and you should do that at some point to try it. However, wait for awhile until you can handle the keyboard commands first. Then give it a shot.
Pick a Team
Like I mentioned, I use VoiceOver as my primary screen reader. You can use more than one, but if you’re new to screen readers, try to stick with one for awhile until you get comfortable. Screen readers are like programming languages: once you learn one, the rest come easier because the principles are the same.
Even though you might become proficient in screen reader use, it’s not the same as using one every day. I’m no expert, just someone who knows how to use one to evaluate a web page from a technical perspective. When I work with more seasoned screen reader users, like on the WordPress Accessibility Team, I give actual users’ opinions more weight than mine. 🙂
Good luck in your screen reading adventures!
When you take on a physical challenge, like a marathon, you have to train. You prepare your legs and mind to accomplish what you set out to do. You can’t just jump in cold and expect to do well.
Yet, as web workers, we go to work each day and dive into many new challenges without much preparation. Yes, we’ve built this type of interface or hooked up to that kind of API, but on the web, while the principles stay the same the methods change. How do we keep up and make sure we’re ready to run the race?
We have to keep our developer fitness level as high as we can. How? Well, I’ll list a handful of things that have worked for me and a few others I’d like to try soon.
Contribute to an Open Source Project
I help out the WordPress project in a few ways and love it. I’ve meet new friends and learned new things. Plus, I’ve had more practice in finding reasonable compromises to tough problems. Find a project that inspires you and get going.
Create Something Simple
I gave a talk about a workflow for testing for web accessibility with free tools at a conference recently. I wanted attendees to have access to the links and information I spoke about, so I created a simple website to house all the resources. It marked the first project I used Grunt, Sass and a few other newish front end development tools. The simplicity kept me focused on learning, not perfecting the project.
Build a Wall
When I landed a new job at Automattic recently, the company bought me a new work computer. I also needed a new personal machine since the one I had was more than six-years-old. So I bought a stock Apple 11-inch Macbook Air and refused to install any web development software on it. Except for ImageOptim, which I use to compress images before uploading them to my blog, you won’t find any dev tools. This has forced me to do more than just write code in my free time. I’m writing more here and reading more, things I wasn’t doing much of before the wall.
At a recent company meetup with Automattic, I watched many of my colleagues give flash talks. These four-minute presentations ranged from technical to silly to personal. Many of them gave me a glimpse of the hobbies my co-workers find interesting, many of which have nothing to do with technology. It made me realize that the main hobbies I have: open source projects and video games are a bit boring. So I want to try a new creative hobby to help stretch my developer fitness in new ways. Maybe the guitar – I once tried to learn to play.
How do you keep your developer fitness up?
Image courtesy of Pexels.com.
You want to make your website more accessible, but you don’t know where to start. If you have 60 seconds, I can help.
Recently, I gave a presentation on how to test for web accessibility with free tools. That was the 30 minute version, but you can also get a broad overview of a site’s accessibility quickly. It won’t tell you everything you want to know, but it will give you a baseline. Use it as you develop your site or application.
Focus on the Basics
- Install the Wave Toolbar or Chrome Extension.
- Use Wave to check your page structure using its “Outline” feature. Do you have a reasonable heading structure?
- Next, also using Wave, turn off CSS. Does your linear source order make sense?
- Again, with Wave, test for any errors. Your images should have alt attributes (icon fonts too). Your clickable elements should be links or buttons and your form elements should have labels.
- Next, test for keyboard accessibility by tabbing through your page or application. Can you get to everything with just a keyboard. Visually, can you see where you are on the page?
If you have any time left, start fixing bugs. 🙂 You’ll probably find some, and that’s okay. What you did doesn’t matter as much as what you do next.
Image courtesy of Pexels.com.
WordPress Accessibility team member Joe Dolson wrote a post on Good Coding Habits for Accessibility, based on a presentation he gave for WordCamp San Fransisco 2014.
Recently, WebAIM announced it would release a Chrome extension version of Wave, its popular web accessibility testing tool. Wave has a popular Firefox add-on and web version, both tools that have always proved indispensable in my accessibility testing.
Plus, WebAIM is also celebrating its 15th birthday! 🙂 I’m excited to see what happens with the Chrome extension, especially since Chrome is my primary development browser.