Simply Accessible We’re accessibility specialists Thu, 16 Aug 2018 01:56:20 +0000 en-US hourly 1 World Usability Day 2017: the deep time edition Wed, 08 Nov 2017 21:43:36 +0000 To celebrate this year’s World Usability Day, the team dug back into the annals of history to curate a list of some of the most exciting developments in digital usability since the dawn of time. Join us in celebrating!

The post World Usability Day 2017: the deep time edition appeared first on Simply Accessible.

Accessible means usable

For us, accessibility is usability. The most accessible digital experiences are the ones everyone can use and enjoy. It’s this wide-open approach to accessibility that has driven us for our whole history as we build a digital world that works for everybody. And we’re bringing that expansive spirit to our celebrations this November 9th as we celebrate World Usability Day.

In honour of the event, the Simply Accessible team thought about some of the most inspiring contributions to usability in the digital world. But we don’t like to limit ourselves (or anyone else for that matter)—so we contemplated usability’s evolution since the dawn of time itself. We’re a pretty diverse group as it is, so we’ve generated an expansive and festive list of star moments in history (and prehistory) that have made the world more usable for all. Enjoy!

In the history of the world, what is one of the most exciting contributions to digital usability?

Caryn Pagel, world usability cruise director

The current digital world—the internet, smartphones, all of it—stems from a desire to communicate. People have been driven to connect with each other since forever. So, when I think about what really impacts usability in today’s digital world, I think about inventions like the telephone or the printing press. Technologies that really helped us reach each other on a grand scale.

Gavin Ogston, world usability hairstylist

For me, one of the most exciting contributions to usability was the development of the JavaScript language. It helped create user experiences that connect people to the information they’re looking for in more natural-feeling ways. It has made information transfer more efficient, which boosts people’s access to information. That’s critical if we’re talking about usability in the digital world where the whole goal is connecting people with the information they need.

Joanna Briggs, world usability smoothie chef

The advancement and, now, ubiquity, of technology have together made observing, recording, and sharing user research much simpler. Early HCI (human-computer interaction) research used film, photography, and video to record their subjects, but now anyone with a mobile phone can record and share. We can connect with people all over the world remotely and observe how they’re using something. While there’s always a place for analog note-taking in a field study, digital tools have improved the usability of doing user research itself.

Jeff Smith, world usability skate sharpener

Apple iOS devices and VoiceOver are my picks. Watching a skilled VoiceOver user navigate not only the web, but things that have been around for ages (phone calls, email, etc.) with speed and ease is an absolutely amazing thing to see. Advances in apps that use augmented reality step even more beyond the digital world in helping make the world in general more accessible.

Elle Waters, world usability unicorn herder

Gender equality. Sometimes we limit who people can be. When we embrace the value of personal experiences that may differ from our own, we also empower them. As we expand our understanding of gender (from just men! to hey, women, too, buddy to all the genders) we train our brains to think more expansively. We recognize the value of a wider range of human expression and experience, and we overcome our own rigid stereotypes. Gender “battles” have been going on since humans first creeped out of the primordial ooze, but the more we treat folks of all genders with dignity, the more we open those creative think tanks. The more we see unique qualities in people as valuable, the more we win with usability and accessibility in general. To create a world that’s more usable for everyone, we start by imagining a world built for everyone.

Joe Watkins, world usability Nicest Guy Ever

One of the coolest things I’ve run into lately is Comcast’s voice recognition feature on their XR remote. They’ve also introduced easy-to-get-to accessibility settings for captioning, video description, and even voice guidance. Just hold down the mic button and say “The Great British Baking Show” and you are all set!

Melanie Jones, world usability clown car driver

At some point in evolution, play became an adaptive behaviour for humans and animals. For some species, it helps young pups imitate adult behaviour and learn important skills, and the same is probably true for human pups. But we’ve taken it a step further. Play is at the root of creativity and innovation. Playful experimentation and curiosity lead to questions like, “How can we do this better?” It leads to beautiful user interfaces and delightful UX. It leads to the impulse to make sure all kinds of people can use and enjoy whatever we make.

Kara VanRoekel, world usability figure skating champion

There is a difference between making the digital world more usable and making it possible in the first place. A lot of innovations over the millennia have made the digital world possible: from the first recorded instances of the written language around 3000 BC (hieroglyphs were the first emojis!), through the work of Ada Lovelace and Charles Babbage on the Analytical Engine, through ENIAC, and to the beginnings of the internet at CERN. But when pressed to pick one single thing that I think helped vastly improve the usability of that world, I’d have to say the development and widespread use of the graphical user interface over the command line interface. The GUI made it easier for millions of people to become involved in the digital revolution.

Charles Callistro, world usability crypto-currency broker

I think digital usability is simply a subset of usability, in much the way accessibility is a subset of good design. If I had to pick an inspiring thing that helped make the digital world more usable, I’d go back to pre-digital, and find an example of recognizing the importance of usability in the first place, like the Army Air Forces Aviation Psychology Program Research Reports. The reports were groundbreaking in recognizing that things works better when things are designed to work better.

Devon Persing, world usability gentleman farmer

For me, the biggest steps forward for usability have been twofold. The first is, through research about learning, information processing, and information acquisition, we now acknowledge that different people have different interaction and information processing styles. The second is that technology now gives us the ability to allow users to customize their digital experiences to best fit their needs. Work and play with a minimum of cognitive load means people can spend more time focusing on what they want to do, and less on how to do it.

Hayley Richardson, world usability tattoo removal specialist

While not necessarily about usability specifically, I think systems thinking (or design thinking) has made one of the most exciting contributions to both usability and accessibility because of how it’s grounded in seeing a problem holistically. Systems thinking puts a problem in context within its own environment to sniff out the best possible solution. This works in the “real” world, and the digital world around us. The best, and most exciting part, is that when working with the big picture like that, you can wind up in a completely different place than where you started. Looking at one aspect of an issue can lead you to a groundbreaking discovery in a completely different, yet related, area.

You’re invited!

At the heart of all our individual responses to this question, some themes emerge: connection, ease, embracing the full range of our shared humanity, delight and creativity, holistic thinking. That is our invitation to all makers and contributors of the digital world on this World Usability Day.

Simply Accessible invites you to open your brains and hearts wide enough to consider all possibilities and people. To embrace inclusive design and accessibility and usability as parts of the same magnificent whole. And to innovate and do better as you make the digital world a more delightfully usable place.

Also, join our World Usability Day party and contribute to our list! What do you think is the most exciting addition to digital usability in the history of the world?

The post World Usability Day 2017: the deep time edition appeared first on Simply Accessible.

Live from Agile Midwest: Lean accessibility on the Technically Speaking podcast Wed, 25 Oct 2017 17:26:02 +0000 Recorded live at the Agile Midwest conference on October 12, Elle's talk about lean accessibility and inclusive design in agile workflows was included in the Technically Speaking podcast. Give it a listen here!

The post Live from Agile Midwest: Lean accessibility on the Technically Speaking podcast appeared first on Simply Accessible.

Catch Elle’s recent Agile Midwest talk, Lean Accessibility: Building inclusive design into your agile workflow, on the Technically Speaking podcast. Feel free to download the transcript of this episode (.txt) or an .mp3 version of the audio.

The post Live from Agile Midwest: Lean accessibility on the Technically Speaking podcast appeared first on Simply Accessible.

Creating accessible React apps Thu, 19 Oct 2017 20:17:48 +0000 The React JavaScript library is a great way to create reusable modular components that can be shared among projects. But how do you ensure your React apps are usable by all kinds of people? Scott takes us through a detailed and timely tutorial on creating accessible React apps.

The post Creating accessible React apps appeared first on Simply Accessible.

Learning React

Way back in February 2017, I took a train from Kingston, Canada to downtown Toronto. Why was I making this two-hour trek? To learn about the React JavaScript library.

By the end of the day-long course, we each developed a fully working application. One of the things that really excited me about React was how it forces you to think modular. Each component does one task, and it does this one thing really well. When building components this way, it helps you focus all your thought and energy into ensuring you get the task right—not just for your current project but for future projects, too. React components are reusable and, if well constructed, can be shared among projects. It’s just a matter of finding the correct Lego brick in the pile to piece together what you need in order to create a great user experience.

However, when I got back from the trip, I started wondering if the app I created that day was accessible. Could it be made to be accessible? After loading up the project on my laptop I set out to conduct some basic testing with my keyboard and VoiceOver screen reader.

There were some minor, quick-win type issues, such as using ul + li elements for the homepage link list instead of the current offering of div elements. Another quick win: adding an empty alt attribute for the callout containers with decorative images.

There were also some more challenging issues to overcome. With each new page load, the title element text didn’t change to reflect the new content. Not only that, but keyboard focus was very poorly managed, which would block keyboard-only users from using the app. When a new page loaded, the focus would remain on the previous page view!

Were there any techniques to use in order to fix these more challenging accessibility issues?

After spending time reading the React docs and trying out some of the techniques acquired during the course, I was able to make the app much more accessible. In this post, I’ll walk you through the most pressing accessibility issues and how to address them, including:

  • React reserved words;
  • updating the page title;
  • managing keyboard focus;
  • creating a live messaging component;
  • code linting, plus a few more thoughts on creating accessible React apps.

Demo app

If seeing code in action is more your style, checkout this post’s accompanying React demo app: TV-Db.

Screen capture of the TV-Db demo app on an iPad. Text in the middle of the screen reads, "Search TV-Db for your favourite TV shows!" A search form is below, along with a few quick links to TV show info pages.

You can also follow along when reading this post by following the in-line links to the source code of the demo app.

Ready to make sure your React apps are more inclusive for people with disabilities and all kinds of users? Let’s go!

HTML attributes and reserved words

One thing to keep in mind when writing HTML in React components is that HTML attributes need to be written in camelCase. This took me by surprise at first, but I quickly got used to it. If you do end up inserting an all lowercase attribute by accident, you’ll receive a friendly warning in the JavaScript console to adjust to camelCase.

For example, the tabindex attribute needs to be written as tabIndex (notice the capitalized ‘I’ character.) The exception to this rule is any data-* or aria-* attributes are still written as you’d expect.

There are also a few reserved words in JavaScript which match specific HTML attribute names. These cannot be written in the same manner you’d expect:

  • for is a reserved word in JavaScript which is used to loop through items. When creating label elements in React components, you must use the htmlFor attribute instead to set the explicit label + input relationship.
  • class is also a reserved word in JavaScript. When assigning a class attribute on an HTML element for styling, it must be written as className instead.

There are likely more attributes to watch for, but so far these are the only conflicts I’ve found when it comes to JavaScript reserved words and HTML attributes. Have you come across any other conflicts? Post that in the comments, and we’ll publish a follow-up post with the whole list!

Setting the page title

Since React apps are SPAs (single page apps) the title element will display the same content set throughout the browsing session; this isn’t ideal.

The page title element is usually the first piece of content announced by screen readers on page load.

It’s essential that the title reflects the content on the page, so people who depend on that and encounter that content first will know what to expect.

In React apps, the content for the title element is set in the public/index.html file, and then never touched again.

We can get around this issue by dynamically setting the title element content in our parent components, or “pages” as required, by assigning a value to the global document.title property. Where we set this is within React’s componentWillMount() lifecycle method. This is a function you use to run snippets of code when the page loads.

For example, if the page is a “Contact us” page with contact information or a contact form, we could call the componentWillMount() lifecycle method like so {Home.js:23}:

componentWillMount() {
  document.title = ‘Contact us | Site Name';

When this component “page” loads, watch as the value in the browser tab updates to “Contact us | Site Name.” Just make sure to add the same code above in order to update the title element for all your page components.

Focus management, part one

Let’s discuss focus management, a large factor in ensuring your app is both accessible and a successful user experience. If your customers are trying to fill out a multi “page” form, and you don’t manage the focus with each view, it’s likely to cause confusion, and if they are using assistive technologies, it may be too difficult for them to continue to complete the form. You could lose them as customers entirely.

In order to set keyboard focus onto a specific element within a component, you need to create what’s called a “function ref,” or ref for short. If you’re just starting out learning React, you can think of a ref in the same light as selecting an HTML element in the DOM with jQuery and caching it in a variable, such as:

var myBtn = $('#myBtn');

One unique thing when creating the ref is that it can be named anything (hopefully something that makes sense to you and the other devs on the team) and doesn’t rely on an id or class for a selector.

For example, if you have a loading screen, it would be ideal to send focus to the “loading” message container in order for a screen reader to announce the current app state. In your loading component, you could create a ref to point to the loading container {Loader.js:29}:

<div tabIndex="-1" ref="{(loadingContainer) => {this.loadingContainer = loadingContainer}}">

When this component is rendered, the function ref fires and creates a “reference” to the element by creating a new class property. In this case, we create a reference to the div called “loadingContainer” and we pass it to a new class property via this.loadingContainer = loadingContainer assignment statement.

We use the ref in the componentDidMount() lifecycle hook to explicitly set focus to the “loading” container when the component loads {Loader.js:12}:

componentDidMount() {

At the point when the loading component is removed from view, you could use a different ref to shift focus elsewhere.

It really can’t be overstated how important it is to manage focus to an element and to manage focus from an element to another one. This is one of the biggest challenges when building single page apps to get accessibility right.

Live messaging

Live messaging is a great way to announce state changes in your app. For example, when data has been added to the page it’s helpful to inform people with certain kinds of assistive technologies, like screen readers, that this occurrence has taken place, along with how many items are now available.

Let’s go through and create a way to handle live announcements by creating a new component. We’re going to call this new component: Announcements.

When the component is rendered, the this.props.message value will be injected into the aria-live element and then this allows it to be announced by screen readers.

The component looks something like {Announcements.js:12}:

import React from 'react';

class Announcements extends React.Component {
    render() {
        return (
            <div className="visuallyhidden" aria-live="polite" aria-atomic="true">

export default Announcements;

This component simply creates a div element with some choice accessibility-related attributes: aria-live and aria-atomic. Screen readers will read these attributes and announce any text in the div out loud for the person using your app to hear. The aria-live attribute is pretty powerful, so use it judiciously.

Additionally, it’s important to always render the Announcement component in the template as some browser/screen reader technologies will not announce content when the aria-live element is dynamically added to the DOM. As a result, this component should always be included in any parent components in your app.

You’d include the Announcement component like so {Results.js:91}:

<Announcements message={this.state.announcementMessage} />

In order to pass the message to the Announcements component, create a state property in the parent component that will be used to contain the message text {Results.js:22}:

this.state = {
    announcementMessage: null

Then, update the state as required {Results.js:62}:

this.setState({announcementMessage: `Total results found: ${data.length}`});

Focus management, part two

We’ve already learned about managing focus using refs, the React concept of creating a variable which points to an element in the DOM. Now, let’s take a look at another very important example using the same concept.

When linking to other pages of your app, you can use the HTML a element. In doing so, this will cause a full page reload as one would expected. However, if you’re using React Router in your app, you have access to the Link component. The Link component actually replaces the tried and true a element in React apps.

Why would you use Link instead of actual HTML anchor links, you ask? While it’s perfectly fine to use HTML links in React components, using the Link component from React Router allows your app to take advantage of React’s virtual DOM. Using the Link component helps to load “pages” much faster as the browser doesn’t need to refresh on a Link click, but they come with a catch.

When using Link components, you need to be aware of where the keyboard focus is placed, and where it will go when the next “page” appears.

This is where our friend ref comes in to to help out.

Link components

A typical Link component looks something like this:

<Link to='/home'>Home</Link>

The syntax should look familiar as it’s quite similar to an HTML a element; swap the a for Link and href with to and you’re set.

As I already mentioned, using Link components instead of HTML links doesn’t refresh the browser. Instead, React Router loads the next component as described in the to prop.

Let’s look at how we can ensure the keyboard focus moves to an appropriate place.

Adjusting keyboard focus

When a new page loads, keyboard focus needs to be explicitly set. Otherwise, focus remains on the previous page, and who knows where focus could end up when someone starts to navigate next? How do we explicitly set focus? Our dear friend ref.

Setting up the ref

To decide where the focus should go, you’ll need to examine how your components have been set up and which widgets are in use. For example, if you have “page” components with child components making up the rest of the page content, you may want to shift focus to the outermost parent element of the page, most likely a div element. From here, someone could navigate through the rest of the page content, much like if there was a full browser refresh.

Let’s create a ref called contentContainer on the outermost parent div, like so {Details.js:84}:

<div ref={(contentContainer) => { this.contentContainer = contentContainer; }} tabIndex="-1" aria-labelledby="pageHeading">

You may have noticed the inclusion of tabIndex and aria-labelledby attributes. The tabIndex with its value set to -1 will allow the normally non-focusable div element to receive keyboard focus, programmatically via ref.

Tip: Just like focus management, use tabIndex="-1" intentionally and according to an explicit plan.

The aria-labelledby attribute value will programmatically associate the heading of the page (perhaps an h1 or h2 element with the id of “pageHeading”) to help describe the current context of where the keyboard is currently focused.

Now that we have the ref created, let’s see how we use it to actually shift focus.

Using the ref

We learned earlier about the componentDidMount() lifecycle method. We can use this again to shift keyboard focus when the page loads inside React’s virtual DOM, using the contentContainer ref we created earlier in the component {Home.js:26}:

componentDidMount() {

The above code tells React, “on component load, shift keyboard focus to the container element.” From this point on, navigation will begin at the top of the page and content will be discoverable as if a full page refresh had occurred.

React’s accessibility code linter

I couldn’t write a React post about accessibility without mentioning the incredible open-source project that is eslint-plugin-jsx-a11y. This is an ESLint plugin, specifically for JSX and React, that watches for and reports any potential accessibility issues with your code. It comes baked in when you create a new React project, so you don’t need to worry about any setup.

For example, if you included an image in your component without an alt attribute, you’d see this in your browser developer tools console:

Screen capture of Chrome’s developer tools console. A warning message states, “img elements must have an alt prop, either with meaningful text, or an empty string for decorative images. (jsx-a11y/alt-text)”

Messages like these are really helpful when developing an app. Although, wouldn’t it be great to see these types of messages in your own code editor, before anything even gets to the browser? Here’s how to install and setup eslint-plugin-jsx-a11y for use with your editing environment.

Install the ESLint plugin

First you’ll need the ESLint plugin installed for your editor. Search your editor’s plugin repositories for “eslint”–chances are there will be something available for you to install.

Here are some quick links for:

Install eslint-plugin-jsx-a11y

The next step is installing eslint-plugin-jsx-a11y via npm. Just issue the following command to install it and ESLint for use within your editor:

npm install eslint eslint-plugin-jsx-a11y --save-dev

After this has finished running, update the project .eslintrc file so ESLint can use the eslint-plugin-jsx-a11y plugin.

Update the ESLint configuration

If there’s no .eslintrc file in the root directory of your project, you can simply create a new file with this as the file name. Check out how to set up the .eslintrc file and some of the rules you can add to configure ESLint to satisfy your project’s requirements.

With the .eslintrc file in place, open it up for editing and add the following to the “plugins” section {.eslintrc:43}:

"plugins": [

This tells our local instance of ESLint to use the jsx-a11y plugin when linting your project files.

In order for ESLint to look for specific accessibility related errors in our code, we also need to specify the ruleset for ESLint to use. You can configure your own rules, but I recommend using the default set, at least to get started.

Add the following to the “extends” section of the .eslintrc file {.eslintrc:47}:

"extends": [

This one line tells ESLint to use the default, recommended rule set, which I find very useful.

After making these edits and restarting your editor, you should now see something like the following when there are accessibility related issues:

Screen capture of Atom text editor. A warning message appears overtop of some code with the following message, “img elements must have an alt prop, either with meaningful text, or an empty string for decorative images. (jsx-a11y/alt-text)”

Continue writing semantic HTML

In the “Thinking in React” help doc, readers are encouraged to create component modules, or component-driven development; tiny, reusable snippets of code. The benefit of this is being able to reuse code from project to project. Imagine, creating an accessible widget for one site, then if the another site requires the same widget, being able to copy and paste the code!

From here, you build up your UI using modules within modules to create larger components, and eventually a “page” comes together. This might pose a bit of a learning curve at first, but after awhile you get used to this way of thinking and might end up enjoying the breakdown process when writing your HTML.

Since React uses ES6 classes to make up its components, it’s up to you to continue to write good, clean, semantic HTML.

As we touched on earlier in the article, there are a few reserved words to watch out for, such as htmlFor and className, but other than this, it’s still your responsibility as a developer to write and test your HTML UI as you normally would.

Also, take advantage of being able to write JavaScript inside your HTML via JSX, when appropriate. It greatly helps to make your app that much more dynamic and accessible.


You’re now fully equipped to make React apps more accessible! You possess the knowledge to:

  • update the page title so people stay oriented within your app and understand the purpose of each view’s content;
  • manage keyboard focus so they can move smoothly through dynamic content without getting lost or confused about what just happened;
  • create a live messaging component to alert people of any important changes in state; and
  • add code linting to your project so you can catch accessibility errors as you work.

And perhaps the best accessibility tip to share with anyone developing for the web: write semantic HTML in your templates, as you would for any static, CMS, or framework-based website. React doesn’t get in your way when it comes to choosing which elements to create for your user interfaces. It’s up to you, dear developer, to ensure that what you create is usable and accessible for as many people as possible.

Have you discovered any other ways to create more accessible React apps? I’d love to hear about it in the comments!

The post Creating accessible React apps appeared first on Simply Accessible.

]]> 4
A smartphone accessibility primer; or, how I learned to stop worrying and master mobile accessibility Wed, 04 Oct 2017 15:45:49 +0000 This is part one of a series of articles that will take you through the basics of mobile accessibility for Android and iPhone, and help you conduct an accessibility assessment on the mobile device of your choice. This week, we’ll start off by comparing TalkBack and VoiceOver screen reader software. Next, we’ll cover the basics of mobile accessibility for fonts and colours, then mobile switch controls, followed by a testing method for mobile for each popular operating system. Welcome aboard, and we hope you enjoy the ride!

The post A smartphone accessibility primer; or, how I learned to stop worrying and master mobile accessibility appeared first on Simply Accessible.

Part 1: mobile screen readers

TalkBack vs. VoiceOver

It has been several years since sales of smartphones and other mobile devices first surpassed sales of traditional desktop computers. More than half of global Internet traffic comes from mobile devices.

Apple iOS started to implement out-of-the-box accessibility features fairly early on, and VoiceOver was introduced with the iPhone 3GS in 2009. Google lagged behind a bit when it came to including its own screen reader, TalkBack, in the Android operating system by default. Because of the early accessibility features on iPhones, as well as the fact that the hardware is very consistent (versus the multitude of devices that could run various versions of the Android operating system), iOS became an early leader in mobile accessibility. Not surprisingly, it became the go-to platform for most people interested in accessibility features.

I started to explore mobile usability both out of personal interest and as an extension of the work I was already doing to learn and implement accessibility on desktops. At the time, I wasn’t a Mac user at all, so I thought it made more sense to go with Android rather than iOS. Even though I had played around with (other people’s) iPhones and seen other people using VoiceOver, my first smartphone was an Android.

When I first started to use TalkBack, I felt pretty awkward. I would slowly follow the green focus outline around the page and fumble my way through the different gestures. It took me a little while to find the proper rhythm, to differentiate between a “slide” and a “swipe,” and to learn the multipart gestures. For me, some of the difficulty was in mastering the timing, since a slide and a swipe are functionally the same, and the only difference between them is the speed of the gesture. (This is analogous to “slide”/”swipe” vs “flick” on iOS with VoiceOver.)  Even so, I still fail to get the proper result for some of the more complicated ones about 30% of the time.

Image depicting the tap gesture for TalkBack Image depicting the L-shaped gesture for TalkBack Image depicting the flick gesture for TalkBack

These images for tap, flick, and right-angle gestures are from the Gestureworks open source gesture library.

What helped me most was learning that when using TalkBack, most of the gestures involve a single-finger tap, flick, or right-angle L-shaped movement. All standard multi-finger smartphone gestures still work while TalkBack is running, but some of the usual single-finger gestures now are performed with multiple fingers. Take scrolling, for example. With TalkBack on, scrolling a web page is a two-finger touch and slide, upgraded from the familiar single-finger gesture. Pinch gestures, because they already use two fingers, work the same regardless of whether or not TalkBack is running. This gave me an easy pattern to follow.

In addition, TalkBack’s focus on single-finger gestures makes it easier to use than VoiceOver by those who are using a single hand to hold and operate the phone, as well as by people with reduced manual mobility or dexterity who might have issues with gestures involving multiple fingers.

Getting started with TalkBack

The TalkBack global context menu (list view)To turn on TalkBack, go to the “Accessibility” option under “Settings.” There’s also an option you can enable to toggle TalkBack on and off, along with a lot of other accessibility options.

If you are familiar with iOS, you might expect to see something here that will allow you to adjust the TalkBack settings. The TalkBack settings are actually available from the Global Context menu, which you can access while TalkBack is on by making an L-shaped gesture down and to the right.

From the TalkBack settings, you can access a tutorial for learning and practicing the gestures, which I found very useful.

TalkBack/Android gestures

Gesture Action
Touch/single tap Read element
Double-tap Activate element
Swipe-right Move to next element
Swipe-left Move to previous element
Two-finger slide up or down Scroll
Triple-tap Zoom
Slide up-down Jump to the first item on the screen
Slide down-up Jump to the last item on the screen
Slide left-right Scroll up one screen
Slide right-left Scroll down one screen
Slide up-left Return to the home screen (from anywhere)
Slide down-left Activate the back button (browser only), close app (apps only)
Slide up-right Opens the local context menu (options depend on where you are)
Slide down-right Opens the global context menu (includes TalkBack settings)

Of all of the TalkBack gestures, the L-shaped gestures are the ones that I have the most difficulty with. I tend to make them too large and slow, so I inevitably “select” a screen element rather than return to the home screen or open one of the context windows.

When I finally got an iOS device, these habitual gesture patterns I relied on actually made it a little bit harder for me to learn and remember the VoiceOver gestures. Only the most basic gestures are the same on both platforms: single-finger gestures to select, activate, and move one element to the right or left.

VoiceOver makes extensive use of multi-touch and multi-fingered flicks, taps, and twists for its interface, as opposed to the single-finger TalkBack gestures, which means a wider variety of commands can be accessed quickly. However, the variety comes with a price, as it might limit what people are able to do with VoiceOver if they have mobility or dexterity issues.

Getting started with VoiceOver

You can turn VoiceOver on by going to “Settings” > “General” > “Accessibility” > “VoiceOver”. You can also access the VoiceOver tutorial, as well as the VoiceOver settings, from there as well.

iOS accessibility settings iOS VoiceOver settings

VoiceOver/iOS gestures

Gesture Action
Touch/single tap Select and read the element
Double-tap Activate the selected element
Swipe-right Move to next the element
Swipe-left Move to previous the element
Swipe up or down On an adjustable element like a slider, this increments or decrements the value. In text view, this moves the insertion point backwards or forwards.
Double press: with one finger, perform a double tap. During the second tap, continue to hold your finger against the screen. Drag the selected item
Two-finger tap Pause/resume reading
Two-finger swipe up Read all accessible items from the top of the screen
Two-finger swipe down Read all accessible items from the current position
Two-finger pinch open/closed Select/deselect text
Three-finger swipe up/down Scroll screen up/down
Three-finger swipe left/right Navigate to the next/previous page
Three-finger double tap (if zoom is enabled, this becomes a three-finger triple tap) Toggle speech
Three-finger triple tap (if zoom is enabled, this becomes a three-finger quadruple tap) Toggle screen curtain
Four-finger tap at the top or bottom of the screen Select the first or last accessible element on the screen

Both TalkBack and VoiceOver allow people to open menus that offer shortcuts to various settings and controls. TalkBack has two: the local context menu and the global context menu. The global context menu is available across all applications and contains commands that work everywhere, as well as general TalkBack settings. The contents of the local context menu vary, and are specific to whatever application is currently active.

TalkBack's local context menu, shown in list form. TalkBack's local context menu, shown in circular form.

VoiceOver has the rotor, a circular single context-sensitive menu of commands. (The VoiceOver rotor is also available on the Mac desktop.) You can open the rotor by placing two fingers on the screen and twisting slightly, like turning a knob. You can also place one finger on the screen and drag another finger around it, though this method requires the use both hands. I find this easier, by far, than opening the local or global context menus. And I like that there is only a single rotor, from which you can access all of your selected shortcuts.

Once the rotor is open, you click through the available options by continuing to twist. I haven’t yet found a way to avoid making this feel awkward when operating with one hand, though the split-tapping option available in VoiceOver does allow both hands to be used, which makes things easier for me.

There are two viewing options for the TalkBack context menus; a circular display, which is very reminiscent of the VoiceOver rotor, and a list display. I prefer the list display, where I can read the full list of available options and easily swipe from one to the other. For sighted users, the rotor has a visual display, but it only displays the current active rotor option, so you won’t know what you can get to until you actually rotate through all of the options.

iPhone's rotor menu

Something that iOS offers screen reader users that Android does not is the ability to blank out the screen for privacy and security reasons. The Screen Curtain option with VoiceOver completely blanks out the screen without impacting the user interaction at all. Up until recently, Android didn’t offer anything this, and while users could reduce the screen brightness, this was not really a substitute for something like Screen Curtain, since the screen brightness on a phone or tablet will never reach 0%.

However, recently Android has introduced Dark Screen, which is their equivalent of Screen Curtain. While I’ve tried both Screen Curtain and Dark Screen, I haven’t used either very much; as a sighted user I don’t feel confident enough using solely a screen reader, so I rely on being able to see the screen and what I am doing.

TalkBack vs. VoiceOver

Having used both TalkBack on Android and VoiceOver on iOS, which is better? In my opinion, both are good options.

VoiceOver gestures are fixed and universal, so moving from one device to another is seamless. The same applies to TalkBack out of the box, but there you also have some control with regards to assigning specific gestures to various commands. All iOS devices have the same basic layout, while Android devices are much more varied, depending on the manufacturer. However, because of this, Android devices do have greater potential for expansion and upgrade options.

In my case, I tend to prefer TalkBack on Android for the simple reason that I’ve used it the longest and it’s most familiar to me. Everyone will have their own unique needs and preferences when it comes to working with mobile accessibility options—but taking the time to learn about what’s available will help you design and create mobile experiences that work for all of us.

I’d love to hear about your experiences working with VoiceOver and TalkBack. Share your thoughts in the comments below.

The post A smartphone accessibility primer; or, how I learned to stop worrying and master mobile accessibility appeared first on Simply Accessible.

]]> 2
Start with empathy Tue, 18 Jul 2017 17:54:55 +0000 While we certainly talk a good technical talk in the accessibility world, the foundation of all our work is empathy. Empathy for our users, and empathy for our clients, is fundamental to why we do what we do.

The post Start with empathy appeared first on Simply Accessible.

The world of digital accessibility is laden with the language of compliance, inclusive design, clean code, and screen readers. So much so that sometimes we forget what really lies beneath our work in accessibility. Why do we do what we do? How do we get people on board with creating accessible sites, products, and services? The answer to these can be found in one word: empathy.

As designers and developers, it’s essential that we include empathy in all our decisions. If your software is not usable for some or all of your users, why are you making it? The people who use your software are the reason you’re making it. You’re not a jerk – we can tell. If you understood how people with disabilities encounter (and sometimes struggle with) your website or application, you’d want to fix it. The more you understand, the greater the empathy you will have.

Foundational empathy

a young woman works at two Apple desktop computersThe very first time I observed a person using a screen reader with a web product I had designed, my jaw dropped. I couldn’t believe what I was seeing. She was unable to perform an essential function of the product, and she thought she was doing something wrong. As I’m fully sighted, I could see the solution right in front of my face, but she had no way of navigating to it. Ever since that day, I’ve been advocating for including accessibility in design and development practices. In my time at Simply Accessible, I’ve observed many more usability sessions with people of varying abilities, but I’ll never forget that first time. It was life-changing for me.

As defined by Merriam-Webster, empathy is the capacity for understanding, being aware of, being sensitive to, and vicariously experiencing the feelings, thoughts, and experience of another of either the past or present without having the feelings, thoughts, and experience fully communicated in an objectively explicit manner.

Everyone on the Simply Accessible team spends our days being aware of and sensitive to the needs and wants of users. We pay particular attention to how varying abilities may change those needs and wants. For example, when a modal window appears on a page, and keyboard focus is not moved into the modal, a person who only uses a keyboard who is sighted will see the modal, but will not be able to access any interactive elements within it, or close the window. The same issue affects non-sighted people who use a screen reader in a different way – they will select the link to open the modal, but they won’t know it opened at all, and they cannot read any of the content. In this example, the root and the solution of the issue are the same, but the issue experienced is different, depending on ability.

You may think it’s awareness and technical knowledge that fixes a situation like that, and you’d be right. But beneath that awareness is always empathy.

Show me an accessible website, product or service, and more often than not you are showing me a designer or developer who cares, deeply, about the user experience.

Inclusive empathy

two women looking at a Mac desktop computer monitorWe had just started reviewing issues that we had reported on their website. I could tell by the question that our client was overwhelmed and didn’t know where to begin. I could also tell she was feeling defeated, and we hadn’t even begun solving her company’s accessibility issues. I feared they were ready to throw in the towel, and we’d really only just gotten the towel out.

“What do you think about creating a separate website for our users with disabilities?” the client asked me, not five minutes into our review session.

I knew we needed to find a way to calm their fears and restore their confidence. I also knew they needed to get their accessibility issues resolved–and soon.

The empathy came out in full force–this time, for the client. As a team, we worked with them on a custom approach to get their own development team started.

Flash forward to today, and their development team is in full swing, well on their way to making their website a welcoming experience for all–no separate website required.

The empathy that’s part of our everyday work at Simply Accessible extends to how we approach our clients. Our clients’ desire to work with us is due to varying motivations. Some are overwhelmed. Some are scared. Most don’t know where to begin. But all have a problem they need solved. We need to understand where each client is coming from, and include empathy in our work with them, for them.

Expansive empathy

When working with clients, we encourage them to expand their own empathy for their users with disabilities. We do this by simply explaining what kinds of issues may happen on their website/app, and what steps people need to take to remedy the issue (if possible). We can tell our clients which technical standard or best practice that they are not complying with until we’re blue in the face, but it’s always the real-life user stories that get through to people.

When we see a group of <a> anchor tags without valid href attributes, there are several ways we could choose to report the issue to our client:

  • The links on the page are not keyboard accessible.
  • The links on the page do not comply with WCAG success criterion “2.1.1 Keyboard.”
  • People with mobility/dexterity issues, who rely on a keyboard, are not able to select the links, because they are not keyboard accessible.

Our team will always choose the third option, explaining what a real user will experience. When you understand the reality your users are facing, you will be motivated to create better site experiences for everyone. By helping our clients in this way, we’re expanding our empathy to include them, which inevitably ripples out to affect their users in a deeper and more attuned way.

The best we can be

five fists bumping together over a deskThe next time you’re engaged in a discussion about accessibility and it doesn’t budge beyond the technical, remember that beneath it all is empathy. The more empathy we have, the better we become at making things accessible. The more awareness we build by demonstrating to clients the need for accessible sites, products, and services. The more understanding we are when working with clients who might be overwhelmed as they start their accessibility journey. And, the more effective our clients become at creating sites, products, and services that meet the needs of everyone.

Upping the empathy quotient among decision-makers, designers, and developers is integral to ensuring the creation of a digital world for everyone.



The post Start with empathy appeared first on Simply Accessible.

Why we do moderated, remote, usability testing Thu, 01 Jun 2017 19:21:45 +0000 Guidelines and specs are helpful in the accessibility world, but they don’t always help us get to the heart of the matter: Is your site, product, service truly usable? Joanna Briggs shares why moderated, remote usability testing is so effective.

The post Why we do moderated, remote, usability testing appeared first on Simply Accessible.

While there are numerous guidelines and technical specs to follow when creating accessible products, they just aren’t enough if you want to truly measure whether you’ve hit the mark. At Simply Accessible, we want to know—really know—the experience someone is having across various digital platforms. User testing isn’t just about finding out whether or not the site works with peoples’ screen readers. It goes beyond functionality to understanding how people with all kinds of disabilities are actually interacting with the digital world—and your product in it—on a day-to-day basis.

Remote testing is effective testing

When it comes to usability studies, there is no win or lose. Usability studies are an opportunity to learn about how people actually use the thing you made, in their lives. To that end, our usability studies look beyond just how the assistive technology (AT) works to include how people use assistive technology. We specialize in moderated, remote usability studies. This is the spice in our recipe.

a desk upon which is a cellphone placed diagonally over a notebook entitled "Field Notes." Behind this, a monitor and a green, leafy plant.When we do moderated, remote sessions, we gain intimate access into other people’s computers and phones. Our participants allow us into their own digital world. Unlike the testing experiences users have likely endured before, where they have to go to an office and work in a room on devices they may not ordinarily work with, we keep individuals in their own home or office environments. In doing so, we gain insight that isn’t otherwise available. We get the most accurate glimpse of a user experience from the words of our participants. Living inside the same experience with people using their own devices, we’re hearing all of it. We’ll hear when a participant says, “Did you hear that? Did you hear what it said?” and get a realtime look at when things don’t work.

Remote testing with our usability testers allows us to observe how something’s used and get honest reactions. When something’s terrible, believe me – they let us know.  We know from manual accessibility testing if something gets focus or gets announced.  But, it’s only a person in a usability session who can tell us if it’s useful, or annoying, or even physically painful. They’re the judge of whether or not an error message makes sense. Maybe they didn’t notice the most important alert at all. Being able to learn in the moment what works and what doesn’t is always revealing, and reminds us of the need for good user experiences over technical compliance, every time.

Unmoderated vs. moderated testing

We’ve tried unmoderated remote testing platforms at Simply Accessible, and honestly, they didn’t give us the answers we (and our clients) need. Foremost, we didn’t find out the why. We couldn’t ask any of the follow-up questions we’re always dying to ask. This is where many insights can be found, in those deeper follow-up discussions. (By the way, auto-generated heat maps don’t show anything when the participant isn’t using a mouse.)

Once, before agreeing to participate in one of our sessions, a participant asked me what Simply Accessible does to accommodate people with different cognitive disabilities. I let her know that we ask first instead of assuming to know what anyone needs. Again, there are no right or wrong answers because we’re here to observe. If anything, the right answer will always be to communicate what the experience is for the user. Accommodations are there for everyone. If someone gets mentally or physically tired, we’ll take a break or finish up another day. Some participants prefer a text chat to communicate with us during the session, so we use that too.

a notebook and mouse in the foreground and in focus, and in the background, a monitor (out of focus)As the head of usability testing at Simply Accessible, the best part of my day is listening to people talk about themselves. I love knowing what’s on their desktop and home screens, why they use one assistive technology (AT) over another, how they use mobile devices, what they love or hate and what’s just annoying. It’s equally amazing to show our clients how their customers with low vision read content on their mobile devices or how someone else may use their voice as a mouse on a desktop computer to navigate a web site.

There are as many unique needs as there are unique users, and I love knowing that the feedback we receive from these sessions goes directly into improving the user experience for everyone.

We aren’t just looking at what assistive hardware and software people use or what apps and browser plug-ins they use. We get to peek into how someone organizes their digital life. Just as with other usability testing, this kind of exploration reveals how people think and what they want when interacting with digital content. For example, in one recent Simply Accessible mobile study, we observed how different people arrange their home screens. While one participant had what first appeared to be multiple screens of chaos, she explained how it was actually an order she created; it works for her.

Another participant with limited dexterity arranged and grouped his iPhone apps into categories on a single screen. This meant he didn’t need to swipe, which is something he prefers avoiding because tapping into a second level is easier. His arrangement of app groups created space around them so that the targets were easier to hit, resulting in fewer mis-taps.

When it comes right down to it, if a site, service or product is poorly designed, someone who has a disability is just going to encounter the same problems as everyone else, only much more pronounced.

If a purchasing process is long and tedious, it’s universally long and tedious. Bad user experiences discriminate against no one. We learn quickly through our usability testing where the problematic issues are, and we also find barriers that might prevent someone from completing a long and tedious task that someone without a disability can complete without as much tedium.

Meet your users

We try to cover a spectrum of people in our usability studies. Sure, it’s not absolutely every scenario, but we do have a wide range of participants that represent all sorts of user needs whether they be auditory, speech, physical, neurological, cognitive, visual or a combination. There’s a brilliant quote from Stephen M. Shore that goes, “If you’ve met one individual with autism, you’ve met one individual with autism.” This speaks to why Simply Accessible includes as many people as we can in our usability work.

a dark-haired woman wearing an earpiece working on her computerIn our studies, we meet our users where they live. Our participants join us from many countries. People have their own unique preferences across many differing devices when it comes to using assistive technology, so instead of trying to recreate the environment they might have in a cold lab, we take our tests directly to them.

When people think of digital accessibility, they commonly just associate it with screen readers. Covering different kinds of screen readers is vitally important – but how is an individual actually using that technology? Screen readers aren’t people – people are people.

Naturally, our participants are using both Mac and Windows on the desktop and iOS, Android and Windows mobile phones and tablets. They’ve got their favourite browsers with plug-ins and add-ons. They have figured out ways to work within the digital landscape and the parameters of their abilities. The information and insight available to us by seeing our participants navigate their digital world is invaluable.

This is how we keep improving

Accessibility has come a long way in the past decade, and the advances in technology that now allow us to facilitate remote usability sessions  have helped us improve and evolve our services. We have gained a deeper understanding of just how different apps, devices, programs, services, and websites are used by people. We have a wider interpretation of “disability” and who accessible guidelines really benefit. Sites, products, services, all of these can’t just be accessible—they have to be usable. Remote testing with real users in their own digital environments is how we make progress when it comes to making things better—for everyone.

Curious about our approach to usability testing? Read more about it here.

The post Why we do moderated, remote, usability testing appeared first on Simply Accessible.

Accessibility down under: Festival of the Web walks its talk Thu, 25 May 2017 17:16:43 +0000 Not just a bunch of quokkas! Julie Grundy shares her experiences at the W3C conference, Web 4 All and Festival of the Web, all held in Perth, Australia last month.

The post Accessibility down under: Festival of the Web walks its talk appeared first on Simply Accessible.

Recently, I attended the Festival of the Web here in Perth, Western Australia, one of the most isolated state capital cities in the world (and my home!) Our isolation has led Perth to cultivate a thriving tech and arts scene, since we can’t rely on anyone to visit us (I’m looking at you, musicians who only tour the east coast!) There is also a huge demand here for reliable internet services to keep us connected to the rest of the world. If you’re excited about human space travel to Mars, why not experience the same exhilarating and risky adventure right here on Earth?

a small quokka - a marsupial native to AustraliaFestival of the Web was created by the Perth tech community to coincide with the annual W3C conference, with several co-located events including the Web 4 All conference. The W3C conference is in a different location each year, and our tourism board got heavily involved to make sure international guests had an opportunity for holiday activities, since people were coming such a long way to be here. Even though we’re in the same time zone as 60% of the global population, we don’t often get international events here. So, when I heard that the W3C was having its conference in Perth this year I was pretty excited. Finally – a chance for people to discover our beautiful beaches, wineries, and cute little quokkas (and enjoy some web talk, too).

Throughout the eight days of the events, over 900 people attended, taking in eleven tracks with academics presenting papers, plus a keynote every day. The list of varied and interesting topics included indoor navigation for people with visual impairments, predicting dyslexia with musical games, and job search and interview process accessibility assessment.There were vendor booths and side events, like dinners, debates, a comedy night and a BBQ. There was even stuff for high school kids on the weekend! It was a lot to take in. In particular, the Festival of the Web was quite different from other design & developer conferences I’ve been to; more informal, but with a lot of serious thinking going on.

As I work in the accessibility sector, and because I love finding out about new assistive technology, the W4A conference was my main focus. The theme of the conference was “The Future of Work,” so there were a lot of topics to do with workplace recruitment, integration and tools for people with disabilities.

In addition to the keynotes and papers, there was an Accessibility Hackathon and a technology demonstration. The hack day goal was to make TAU, an open-source assessment tool, more accessible. Teams were made up of people with different skills – some were accessibility experts, some were developers, some were designers, some were content authors, and at least one person with a disability was in one of these roles on each team. The winning team members each got to take home an X-Box! It was encouraging to watch people working together for a common goal, and having a lot of fun doing it.

In a field that is often fraught with the idea that “accessibility is hard,” it was exciting to see just how much fun it can be.

A truly accessible conference

Two large monitor screens display the live captioning of the speaker's words on either side of the stage. The MC is still on stage, having just introduced the speaker. The lady standing next to the speaker is an Auslan (Australian Sign Language) interpreter and she signs the speaker's talk. The speaker, Bill Grussenmeyer, is blind and used the ramps to the side of the stage to make it easier for him to step up onto the stage.What I most enjoyed about W4A was the effort the organizers made to create a truly accessible conference for all to participate in. There were ramps to the podium making it easier for people with vision or mobility impairments to get to their presentations. There was live captioning displayed on two large screens, and it was also available on the web for people who couldn’t be present in a session or preferred to use their own device instead of the screens. There were two Auslan (Australian sign language) interpreters as well, taking turns signing. The organising committee made sure everyone could join in on all activities.

A screengrab from the author's iPhone, showing the website with the live caption of one of the keynote speeches.I had the opportunity to chat with people from large accessibility consultancies as well as universities, and talk shop with people researching the future of assistive devices. It was wonderful to do this in person instead of just following them on Twitter (or downloading their papers then forgetting to actually read them!)

Everyone welcomed our local Perth accessibility developers and consultants into their conversations. I felt like I was really part of a community, not just an industry.

Building the future, one demo at a time

The demonstration afternoon was by far my favourite part of the event. Tables with researchers and their assistive technologies were set up, and people moved from table to table to ask questions and learn. We got an up close introduction to some amazing innovations. Congratulations to Gaze the Web and VizLens for winning the day!

After the W4A conference was over, there were still four days left of the main conference. I went to the keynotes each morning and sat in on sessions for computational health and the W3C committees on privacy and security, and spatial data. All of the papers can be read on the W3C Conference website, and I think they will release some videos of the keynotes later on. I also spent time in the Technical Expo room, eating the snacks and lunches provided every day. I wish I’d taken a photo of the salted-caramel and chocolate brownies, they were delicious!

Meet us in Lyon 2018

The author Julie on right and her friend Ruchi to the left in the keynote auditorium.Next year the W3C conference and the W4A event will be held in Lyon, France. If you are nearby, or can find an excuse to travel to France, I highly recommend you make time to attend. Many folks from the Simply Accessible team will be there! At this year’s W4A, I felt so inspired by the work people are doing, and I learned a lot about where the technology is heading.

Given that the next one is in France, I’m pretty sure the conference food will be even better than our brownies.

The post Accessibility down under: Festival of the Web walks its talk appeared first on Simply Accessible.

Creating accessible forms with Angular Thu, 18 May 2017 18:17:11 +0000 Forms are integral to the online experience, and a well-written form structure ensures the forms you make are easy to use - for everyone. In this post, Scott Vinkle offers solutions discovered by himself and the Simply Accessible team when it comes to creating accessible forms in Angular.

The post Creating accessible forms with Angular appeared first on Simply Accessible.

hands typing on a keyboard and code on a black screen on the monitor

Online forms are the foundation of communication in the modern age. Without forms, all we’d have would be static text websites with pictures of cats to look at. Sure, it doesn’t sound too bad, but without forms, how would we discuss and share cat pictures with all our friends and family? How about shopping online, booking a flight, ordering pizza late at night, or setting up a time to meet on that dating site?

This, dear reader, is why well-written form structure using semantic elements and input validation is critical to the success of any web form. Who will be filling out our forms? On which platform or device? In the comfort of their home or on a busy bus ride?

We can’t really anticipate where someone might be or what device will be used, but we can make sure our forms are easy to use and easy to complete for as many user groups as possible.

Recently, we’ve been looking at examples of forms created with Angular from an accessibility perspective. For the most part, it seems like things have improved over the years from our original AngularJS article, Single page applications, Angular.js and accessibility. Most example forms we see now include explicit label/input pairs, which help provide context on the type of content expected. It’s great to know developers are including this accessibility win by default!

When searching for examples of Angular forms and how they’re set up, we noticed a trend that may have been ported over from AngularJS examples: a suggested approach when designing and developing forms to include inline validation and reserving the submit control in a disabled state until valid data has been entered. While this paradigm may seem more modern and may help the user complete the form successfully, there are a few usability and accessibility issues that appear when this workflow is implemented.

We’ll explore these concepts in-depth, discuss why they might not be the best solution for your users, and offer practical, more inclusive solutions which can be implemented within your Angular forms.

Trending workflow

When reviewing the example approaches provided, we see two trends in particular: encouraging inline-validation of each form control after it’s been “touched” (essentially when the user moves away from the input) and keeping the submit button in a disabled state until each validation test has been satisfied.

Inline validation

We typically recommend not using inline validation, as this method has the potential to cause the user a bit of confusion or frustration at times. Some examples illustrating this include:

  • When someone using a screen reader is navigating through a form to get a lay-of-the-land, trying to read what each field is and the expected data
  • Someone who might want to fill in fields in a different order
  • When someone leaves a field to go look something up to be certain of what data to place within the form control

These simple actions trigger the error message and the result can be quite irritating.

In our own usability studies, people often grumble or curse out loud when error messages appear before they’ve even started filling out forms!

Additional accessibility issues appear when the user navigates away from a field; the error message is displayed visually but not to assistive technology. In order to hear the error message, the user needs to navigate backward through the form. This would be an unexpected required action to hear error messages.

Disabled state

With the submit button set as disabled by default, only after all of the form validation rules have been satisfied does the submit button become available for use. Having this in place might lead to a confusing or frustrating user experience; there’s no indication as to why the submit button would be disabled after filling in the form.

Consequently, disabled buttons can present two additional challenges for individuals:

  1. People who have low vision might not be able to perceive the button text in the dimmed state.
  2. Some assistive technology will skip disabled elements; screen reader users may not get a full picture of what is available in the interface, leading to feelings of uncertainty.

Example form

In the example linked below, we have a common “Contact Us” style form. This form features the workflow described above, including the trends of testing the input validity after the control has been interacted with and the disabled submit button by default:

Behind the scenes

Here’s what’s happening in the code to make this current workflow take place:

For each form input control requiring validation, there exists an *ngIf directive. This directive tests two conditions:

  1. Test the validation condition using the contactForm.controls[name].hasError() method
  2. Test the state of the control using the contactForm.controls[name].touched flag
<div *ngIf="contactForm.controls['firstName'].hasError('required') && contactForm.controls['firstName'].touched">You must include a First Name.</div>

Since each condition statement uses the “and” clause, both conditions need to be met in order to show the input error message. Basically, these conditions state, “When the user moves away from the input control, check the validity of the data. If the data is not valid, show the error message.”

The submit button features the [disabled]="!contactForm.valid" property binding. This binding holds the button in a disabled state until the form data is completely valid. Only then will the user be able to find and activate the button.

<button type="submit" [disabled]="!contactForm.valid">Submit</button>

Accounting for accessibility with this workflow

To alleviate some of these potential pain points for your users, we recommend taking a different approach altogether. Consider making the following changes to your form workflow:

  1. Allow validation to happen on initial form submission by keeping the submit button enabled. This will allow the user to easily explore the form and become comfortable with the form structure on the first run through. Even if the form fields have errors, allow users to submit the form on their terms, when they feel comfortable to do so. To do this, we simply remove the [disabled] property binding from the submit button.
    <button type="submit">Submit</button>
  2. Add a new class property, submitted, which will serve as a boolean flag. By default, its value will be false. When the form submit button is clicked, update its value to true. This property will be used within the template as part of the *ngIf directive when checking our validation rules and whether to show an error message.
    export class ContactFormComponent {
      submitted: boolean;
      // ...
      submitForm(value: any) {
        this.submitted = true;
        // ...
  3. When an input is in an error state, output the error message text within its corresponding label. This will serve as a reminder of the error and the expected value when the control is navigated to, as well as any other controls in an error state when the user moves forward through the form content.
    <label for="firstName">
      <input id="firstName" type="text" [formControl]="contactForm.controls['firstName']">
      <div *ngIf="contactForm.controls['firstName'].hasError('required') && submitted">You must include a First Name.</div>

Bonus: This also has the benefit of creating a much larger click/tap area for people who are using a mouse or mobile device, since the labels themselves are targets!

We can check if the input is in an error state by adjusting the *ngIf directive. Continue using the controls[name].hasError() method to test the validity of the input value, but remove the controls[name].touched flag as we no longer need this property. Here’s where we can use the new submitted property to see if the form has been submitted. If the input value is invalid and the form has been submitted, display the error message.

Turbocharging your forms with next-level accessibility

So far we’ve addressed the flow issues with this approach by removing the disabled state of the submit button by default and by validating each input after initial submission. There are a few extra steps we can take to greatly increase the overall accessibility of any large/complex form. To avoid over-engineering, short forms such as a login form, would be exempt from the following:

  1. If there are errors to display, output each error message in a ul list at the top of the form, above the form fields. When this list is visually presented, programmatically shift keyboard focus to the top of the list, preferably a heading element. This will provide a notification that something happened after clicking the submit button, that there are errors to be fixed and the total number of errors (via ul list item count). Implementing each error message in a list helps users to understand and then navigate to correct the errors. In the submitForm() method, select the heading and apply focus() when the form returns invalid.
    <ul id="error-list">
      <li *ngIf="contactForm.controls['firstName'].hasError('required')">
  2. For each error message in the ul list, implement the text as an link which points to the corresponding input control, via matching its id value with the href attribute of the link. With this in place, users will be able to hear the error message text and have a shortcut directly to the input in question, which is helpful for users with dexterity issues who rely on the keyboard.
    <a href="#firstName">You must include a First Name</a>
    <input id="firstName" type="text" [formControl]="contactForm.controls['firstName']">
  3. Ensure that any required fields are conveyed to all users by having a visual “*” (required) indicator with a text alternative for assistive technology users. This will help all users understand which parts of the form need to be completed and which can be skipped. This could even be an SVG image with alternative text!
    <span aria-hidden="true">*</span>
    <span class="visuallyhidden">Required</span>

Putting it all together

Here’s our example form again, but with the recommendations as described above:

With these changes in place, anyone relying on assistive technology or those who need a little more guidance in completing a form will have a clearer understanding of how the form is structured and the current state of the form, if there are any errors and how to address them. If there are changes to be made on submit, focus will be brought up to the error listing. From there, error links will move focus directly to the form input in question. From this point, error messages will be announced when traversing the form, and any changes to the data can easily be made with greater confidence on the part of the user.

Keep in mind, this recommended workflow is not specific to Angular forms. The techniques and concepts explored in this post can be applied to any form, using any JavaScript framework or library.

Angular is able to support accessibility features, but developers still need to make sure the implementation meets the needs of all users.

The key takeaway is to make sure your users are able to discover the layout and inputs of the form, and to complete their task of filling out the form you’ve designed. They’ll have confidence and assurance that they’ve done the right thing, and both of your goals are met!

Consider enhancing the flow of your Angular forms with these suggestions in order to help guide your users in successfully completing forms with ease.

The post Creating accessible forms with Angular appeared first on Simply Accessible.

I’m still here: a career in accessibility Thu, 04 May 2017 13:00:23 +0000 The story of accessibility is the story of humans connecting to each other. In this post, Jeff Smith reveals why he got into accessibility, and what keeps him here.

The post I’m still here: a career in accessibility appeared first on Simply Accessible.

Before there was colour contrast, before there was accessibility, before there were even computers in my life, there was my buddy Graham.

Two small boys seen from behind, walking in a grassy meadow; one boy holding the other's arm.My best friend since age 4, Graham was born with oculocutaneous albinism, a form of albinism that, in Graham’s case, resulted in low vision and colour blindness.

As we entered junior high school, home computers were becoming more common. We were both really into music and we spent hours looking up guitar tablature online for our favourite songs. I watched as  Graham struggled with seeing the screen and the tiny diagrams for the guitar tabs. Through Graham’s experience, I learned about what assistive technology was available from the Canadian National Institute for the Blind (CNIB). This consisted of monitor magnifiers, large magnifying glasses and different types of screen magnifying software.

Still, Graham had difficulty. While using a screen magnifier, many necessary elements on pages would be out of his view. When he read content on the web or navigated through pages with forms he would often sit very close to the screen in uncomfortable positions to avoid using a screen magnifier. Doing so would ensure that he’d be able to scan the screen to locate those items that would normally have been out of his view. Looking back, I can see how this could have set Graham up for potential back issues and other injuries later in life.

Focus management

During high school, I developed a strong interest in web design and development. However, none of my preferred universities were offering web development programs. The next logical step for me was computer science and software engineering. I chose to place a heavy focus on human computer interaction (HCI). The HCI courses provided some focus on digital design and web technologies.

Although I wasn’t yet aware of the digital accessibility movement, I knew something was missing when it came to the HCI curriculum in the classes I took.

I couldn’t understand why it didn’t include any consideration for vision disabilities.There was a gap in my computer science education, a gap that I had been witnessing my best buddy struggle with for years.

I moved on in my studies, pursuing a diploma in graphic design. My studies placed a heavy focus on colour theory and how it applies to colour blindness. Immediately after graduation, I began freelancing in web design and development.

Discussing colour blindness with clients led me to experience hesitation and pushback. Some clients wondered why they should even worry about it, while others were concerned about the ripple effect of changing their branding on the web. I knew I needed more fortification to back up my reasoning. The more I learned, the more I began to fly under the radar, making slight colour changes that made user experiences better for everyone.

I was just doing what I knew was right—and in doing so, I rarely ran into pushback.

Getting connected

As I met more and more developers and designers online that were also interested in improving the digital experience for everyone, it was just a matter of time before I connected with Derek Featherstone through an online mailing list. Derek is among the most prominent leaders in the digital accessibility space and I regularly bounced ideas off him when I ran into new, challenging issues in my work.

Tired of the freelance rollercoaster, I took a position at a small Microsoft .Net shop. At the time, .Net components were incredibly inaccessible out of the box. I began teaching my co-workers about some of the accessible development techniques I had been learning in my free time. Again, I ran into resistance from project managers and clients worried that creating an accessible user experience was adding more time and cost to our projects. I flew under the radar once more, working with our developers to convert all our .Net controls into custom, accessible controls. We were essentially building out a pattern library that had accessibility baked into it. Still, I didn’t feel like we were doing enough for our client’s end users. I was craving the opportunity to do more, since it was clear to me that there was so much more to be done.

Up close and personal

In early 2007, I began working as a developer with Derek. As I continued to refine my accessibility skills, I also began learning more about advanced manual accessibility testing and accessible design. The more I worked with Derek, the more my passion for accessibility grew. I got a closer look at the incredible barriers that users with varying disabilities face on the web.

Soon, I found myself working closely with our client’s development and design teams. Through this, I saw that many people didn’t believe accessibility was their responsibility. Still others were daunted by the task of adding yet another skill to the already mountainous list of technology they need to stay ahead of.

I made it my goal to work with developers. I wanted to show them that incorporating basic accessibility practices into their workflows didn’t require extra work. I wanted to show them that quite often these practices contributed to things they were already thinking about, like web standards, and test-driven development.

As I moved into the role of Director of Operations at Simply Accessible, my new challenge became helping discover better and more efficient ways for our team to help clients to incorporate accessibility into all aspects of their digital practice.

While my focus has shifted away from testing and working side-by-side with our client’s development teams, I still very much believe that the key to making the digital world more accessible is reaching the artists and builders of the web, the designers and developers.

Turning designers and developers into believers in accessibility, and finding champions in that group, can trigger mind-shifts that have a lasting impact within companies. Product/team managers and decision-makers will start to see the benefits of these practices through results like an increase in conversions for their business and less stress on their customer support teams.

The journey continues

I’m still here because I hope to see many more people embark on the accessibility journey I’ve been on since my early 20’s. I want to see people start with something seemingly small, for instance, colour contrast or keyboard accessibility, and grow to the point where we’re all thinking about digital accessibility beyond the web: mobile devices, kiosks, self-serve checkouts in stores, and so on. And finally, I want to help more people think beyond digital accessibility, to education, the physical space, and more.

Silhouette of two boys playing guitars with the sunset behind them.As for Graham, he and I are still good friends. He now leads a branch of a large investment management company and is still very much involved in music. Every so often we’ll discuss the issues he runs into on the web, but advances in both optical and assistive technology have made his online life easier. I keep doing what I do, so Graham can keep doing what he does.

The post I’m still here: a career in accessibility appeared first on Simply Accessible.

]]> 4
Demystifying accessible name Thu, 30 Mar 2017 21:52:16 +0000 When it comes to creating accessible products, understanding the interactions between different technologies and the code we write is very helpful. In this post, Joe Watkins talks about accessible name--what it is, how to apply it, and why it's such an integral tool in the accessibility toolkit.

The post Demystifying accessible name appeared first on Simply Accessible.

I remember the day, digging around the W3C’s documentation, I stumbled upon the definition of the Accessibility API. After jumping into the Accessibility API rabbit hole, it occurred to me that there is a huge world of behind-the-scenes technology supporting a dance between browsers and assistive technology. This journey led me to Accessible Name.

It’s important to write clean, standards-based code, as we know. Once I learned about accessible name, however, I realized the importance of having a high-level understanding of the interactions between different technologies and the code we write. This helps bridge the gap between the how and the why.

Accessible name is the name of a user interface element. Its value is a big part of what is communicated to users of assistive technology. Without it, people who rely on those technologies would have difficulty understanding or interacting with much of the content on the page. Once I understood what accessible name was, and its critical role in web accessibility, I was on my way to creating more accessible experiences.

In this article, I’ll explain accessible name and how assistive technologies interact with web browsers. Together, we’ll explore some code examples. Finally, I’ll show you a cool new accessibility browser tool so you can test for accessible name and feel confident that the code you write is more accessible than ever!

Assistive technology is separate technology

Before we talk about accessible name, we should first understand that assistive technology, like a screen reader, is a separate application that works along with a web browser. VoiceOver is not part of Safari, JAWS is not part of IE, and NVDA is not part of Firefox.

Because screen readers are separate applications and not built into web browsers, they need a mechanism for getting the content from the web browser to the person using them. Let’s explore how assistive technology (AT) is able to interface with the web browser, using a screen reader as one of the most common types of AT that people use.

Graphical representation of a web browser and a screen reader but nothing connecting them programmatically. The disconnection is represented with a question mark and arrows pointing in each direction.

The accessibility API

You may be familiar with the concept of an API or Application Programming Interface. Let’s say we were developing a website and we wanted to get the last 20 tweets from a particular Twitter user. There needs to be an interface between our website and Twitter to establish a connection and pass along the data we want to use. That is the API–without it, we wouldn’t be able to connect to Twitter and get the data we want.

The screen reader has access to what is called the Accessibility API. It is very similar to the DOM API. The operating system exposes objects and events to assistive technology through this API. This is the connector we need to get the information from the web browser to the screen reader. Well, we don’t need it — it all happens automatically — we just need to understand the basic mechanics.

The screen reader can also communicate user interactions and commands back to the web browser to interpret using the accessibility API.

Graphical representation of a web browser communicating with the accessibility API which is being interacted with by a screen reader. This communication between web browser, accessibility API, and screen reader is depicted with arrows going back and forth.

The accessibility tree

The web browser converts the DOM into what is called the Accessibility Tree which is a tree of objects that represent the structure of the user interface. If you were 10 years old again and climbed this tree, you’d find many nested branches with leaves, or nodes, which represent  HTML elements, e.g. button, input field, or div.

This tree is what is exposed to assistive technology via the accessibility API.

Screenshot of the Accessibility inspection features for Chrome Developer Tools enabled and open inspecting the document. From the Elements tab the Accessibility sub-tab is chosen, and a representation of the accessibility tree is pointed to and highlighted.

The image above is a screenshot of the Accessibility inspection features for Chrome Developer Tools enabled with the accessibility tab selected. When you inspect an element you are given a bird’s eye view of the accessibility tree.

To enable this feature/experiment in Chrome, watch this screencast video below or follow these steps:

  1. Using Chrome, open the Chrome Flags by visiting this url: chrome://flags
  2. Search for “Developer Tools experiments” and enable those.
  3. Use Ctrl+Shift+I (or Cmd+Opt+I on Mac) to open the DevTools.
  4. Go to Settings -> Experiments -> check Accessibility Inspection
  5. Close DevTools and reopen.
  6. Select Elements and inspect an element.
  7. You can find the Accessibility tab in the same row as Styles, Computed, Event Listeners.

Video description: Screencast video, with no sound, demonstrating how to enable the accessibility inspection features for Chrome Developer Tools experiment.

Accessible name

Many elements in the accessibility tree need a name so they are clearly communicated to assistive technology. That name is the accessible name. The accessible name is part of what is announced by a screen reader when that element receives focus. The value of the accessible name can be both visual content or hidden text alternatives. Not every single element in the DOM needs an accessible name. For example, non-semantic elements used for style or presentation only such as  <div> or <span> do not need an accessible name defined.

The examples below were tested using the VoiceOver screen reader with Safari.

Not good:

<button type=”submit”></button>
  • The accessible name for this button is: “”
  • VoiceOver announces: “button”
  • Why? There is no text inside the <button> element.


<button type=”submit”>Update Details</button>
  • The accessible name for this button is: “Update Details”
  • VoiceOver announces: “Update Details, button”
  • Why? The text inside the element is the accessible name.

Not good:

<input type="submit">
  • The accessible name for this button is: “submit”
  • VoiceOver announces: “submit, button”
  • Why? There is no value attribute defining the action or accessible name. “Submit” may not be a suitable action for the input in all cases. Some AT may inaccurately try to guess what the accessible name is if one isn’t defined. Browser default values for these inputs, without value attributes defined, may not be consistent.


<input type="submit" value="Update Details">
  • The accessible name for the input element is: Update Details
  • VoiceOver announces: “Update details, button”
  • Why? The accessible name is delivered via the value attribute.

Not good:

<img src=”34422_some-file_2bsca.jpg”>
  • The accessible name for the image is: “”
  • VoiceOver announces: “Thirty four thousand four hundred and twenty two some file two bcsa jpg, image”
  • Why? The img tag is missing an alt attribute so the screen reader announces file name.


<img src=”file.jpg” alt="Woman holding a baby">
  • The accessible name for the image is: “Woman holding a baby”
  • VoiceOver announces: “Woman holding a baby, image”
  • Why? The img tag has an alt attribute with a descriptive value.

Not good:

<input id=”search” type=”text”> 
  • The accessible name for the input field is: “”
  • VoiceOver announces: “edit text”
  • Why? The input field is missing an associated <label>


<label for=”search”>Search</label>
<input id=”search” type=”text”>
  • The accessible name for the input field is: “Search”
  • VoiceOver announces: “Search, edit text”
  • Why? The <label> is programmatically associated with the input field when the for attribute matches the value of the id.

Not good:

<div class=”hamburger-menu”>
  <span class=”line”></span>
  <span class=”line”></span>
  <span class=”line”></span>


<a href=”#hamburger-menu” class=”hamburger-menu”>
  <span class=”visually-hidden”>Menu</span>
  <span class=”line” aria-hidden=”true”></span>
  <span class=”line” aria-hidden=”true”></span>
  <span class=”line” aria-hidden=”true”></span>
  • The accessible name for the hamburger menu trigger is: “Menu”
  • VoiceOver announces: “Menu, link”
  • Why? The link is focusable by a keyboard and assistive technology as well as having visually hidden text content.


<h1>We're building a digital world for everyone</h1>
  • The accessible name for the heading is: “We’re building a digital world for everyone”
  • VoiceOver announces: “We’re building a digital world for everyone, heading level one”
  • Why? The element has visual text content.


<some-custom-element aria-label=”I am a custom critter” tabindex=”0” role=”button”>...</some-custom-element>
  • The accessible name for the custom element is: I am a custom critter
  • VoiceOver announces: “I am a custom critter, button”
  • Why? The custom element is focusable because of tabindex=”0” and has been given an accessible name with aria-label=”…”

P.S. Just use a <button> 🙂

In the examples above, we can hear the screen reader announce the accessible name. In addition to announcing the accessible name, the screen reader announces the role of the element, e.g. button, image, edit text, heading.

Other methods of adding an accessible name to an element are using attributes like aria-labelledby, aria-label, and even the title attribute (Use title with caution).

Test for accessible name

To test for accessible name you can use a screen reader and listen to how that element is announced.

In the video below, we send focus to an input field that does not have an accessible name defined and “edit text, blank” is announced by the screen reader. A non-sighted screen reader user would not understand what that form field is for.

From the code, we programmatically tie the label to the input field with the for attribute and the accessible name is then announced by the screen reader when the input field receives focus, e.g. “First Name, edit text”

Another way to test for accessible name is using the accessibility inspection features we installed earlier in this post. In the video below, we open the Chrome DevTools and choose the elements tab. We then choose the accessibility tab over by the styles tab. From there, we can see the name property that shows what will be announced by a screen reader.

The importance of accessible name

By including a meaningful accessible name in everything you create, you are well on your way to making sure these elements will be communicated clearly to screen reader users and made available to other assistive technologies like voice recognition software. Form fields will have labels, buttons will have text, images will have text alternatives, and this old world will be a little more inclusive!

Now that you have an understanding of why accessible name is important to consider when developing, get out there and test your own creations for it. Feel free to ping us in the comments if you have any questions or thoughts.

The post Demystifying accessible name appeared first on Simply Accessible.

]]> 2
7 solutions for creating more accessible SVGs Thu, 16 Mar 2017 21:17:49 +0000 We’ve been working with SVGs a lot recently, which has led our developers down a rabbithole of discovery! Here are some things to consider when it comes to SVGs and accessibility.

The post 7 solutions for creating more accessible SVGs appeared first on Simply Accessible.

When it comes to displaying images online nowadays, designers and developers have plenty of great formats from which to choose. There’s the ubiquitous GIF (Graphics Interchange Format), the universal JPEG (Joint Photographic Experts Group), and the animated SVG (Scalable Vector Graphics), to name just a few. How do you know which one to use in your designs? Are any of these more amenable to creating an accessible site?

While we don’t like to pick favourites, our clients are choosing SVGs more and more, which means we’re working with SVGs more and more. As a result, we’ve learned the ins and outs of this image format, and how to make them accessible. And now, we want to share all that goodness with you!

A closer look at SVGs

Scalable Vector Graphics, otherwise known as SVGs, are a useful way to display images: they can scale smoothly, and they lack issues that exist with icon fonts, which can cause challenges for users with reading disabilities and parsing errors with some screen readers, depending on how they’re implemented. SVGs also give designers and developers a lot of flexibility in creating complex graphics natively and dynamically.

Many of our clients use SVGs to display their images, which is great. However, the way in which SVGs are implemented can affect users with disabilities in a big way. To that end, we’ve put together a roundup of the most common challenges we’re seeing with SVGs right now and how to address them, along with some examples for you to try out yourself.

1. <img> tags and SVGs

When SVGs are implemented as <img> tags with an .svg as the source, we’ve encountered a few issues for VoiceOver and TalkBack users. These issues occur when those <img> tags don’t also have an ARIA role=”img” attribute.

See the Pen Images with .svg file examples by Devon Persing (@dpersing) on CodePen.

  • VoiceOver/Safari on desktop will read an alt value but does not identify the image as such without the role, and it doesn’t show up in the image list in the rotor.
  • VoiceOver/Safari on mobile skips the image entirely, even if there is an alt value, without the role.

If the image is part of a link, both have the same result:

  • VoiceOver/Safari on desktop reads the alt value as the link content, but does not identify the image, without the role.
  • VoiceOver/Safari on mobile reads the alt value as the link content, but does not identify it as part of an image, without the role.

TalkBack with Chrome and Firefox will identify the SVG as an image either way, unless it’s part of a link. Then, the alt value is identified as the link text, but no image is mentioned. This might not be a problem if the fact that the link content is an image doesn’t matter, but it might potentially cause problems. It’s usually safest to just include the role!

2. <title> tags and SVGs

We often see examples of making SVGs accessible by simply adding a <title> element within the inline <svg>. While this does help in some situations, like a lone SVG icon within a link, adding a <title> element doesn’t make SVGs accessible in all browsing environments.

See the Pen Inline SVG title pattern by Scott Vinkle (@svinkle) on CodePen.

For example, when using Firefox and NVDA, a link containing an SVG would be recognized as a link, but the text within the <title> element would not be announced. NVDA announces the path within the href attribute only.

Adding an aria-labelledby attribute to the SVG can help expose the text within the <title> element to the browser’s accessibility API. However, even with this in place, NVDA does not announce the <title> text as we might expect.

Our most recommended approach when it comes to browser support and consistency across screen readers is to add a visually-hidden element as a sibling element to the <svg>. With this implementation, we’ve found that all browser and screen reader combinations tested were able to announce the link with the expected text announcement.

We also recommend adding aria-hidden=”true” to the <svg> element itself. This is to help prevent having any other text that may be embedded within the SVG be announced by screen readers. Then, the only text that should be announced would be the content within that visually-hidden element.

3. IE focus bug with focusable elements

The <svg> elements inside focusable elements (like links or buttons) in Internet Explorer default to focusable=”true” due to a bug. This causes both the parent element and the <svg> to receive focus. The focus indicator disappears when the image file receives focus, which is a problem for sighted keyboard-only users. Additionally, some screen readers read the content twice since parts of it get focus twice.

The way to fix this is to add focusable=”false” to the <svg> to set the attribute to what it should be by default.

Here’s an example with the focus broken, and here’s one with the focus fixed.

Hop over to StackOverflow for some more discussion on the topic.

4. Safari 10 focus bug with <use>

When accessed in Safari 10, <svg> that have <use> elements without whitespace between the parent <svg> and child <use> tags prevent focus from moving past the <svg>. This is an issue for all desktop Safari keyboard users. This is fixed in WebKit Nightly, so it may not affect more tech-savvy users, but users who keep Safari up to date in the normal channels will run into problems.

The solution, thankfully, is to just add whitespace around the <use> tags like so:

<svg> <use>...</use> </svg>

Check out some more discussion on VoiceOver and <use> over at

5. Aria-label inconsistency

Another VoiceOver issue! An aria-label value reads consistently on <svg> elements that are children of a focusable control, like a link or button, but it’s skipped by VoiceOver/Safari on iOS and OS X/macOS when the aria-label is used on a non-focusable element.

To prevent conflicts, we recommend using aria-hidden on the <svg> and using CSS to visually hide a text equivalent instead of relying on aria-label or similar techniques, just like we recommend for the <title> scenario discussed earlier.

See the Pen SVG and aria-label by Jeff Smith (@jeffsmith) on CodePen.

6. IE8 and below render <desc>

Internet Explorer 8 and below will visually render the content found in the <desc>…</desc> tags. A conditional can be used to hide this from old Internet Explorer versions.

See the Pen Inline SVG w/PNG Fallback by Joe Watkins (@joe-watkins) on CodePen.

7. Colour contrast

While not a bug per se, we also see a lot of cases where designers and developers don’t plan for colour contrast issues for SVGs. Since SVGs function just like transparent GIFs in how they are displayed, different page background colors and effects can cause unanticipated issues for low vision users.

For example, a black SVG icon that’s perfectly visible with a white page background is going to be invisible in a Windows High Contrast theme that uses a black background. This is a common use case for users who use High Contrast settings due to light sensitivity or related issues. When you provide a solid background or contrasting border for SVGs, you can help avoid those kinds of problems.

What have you found?

Every image format has its pros and cons, and SVGs are no different. In spite of these potential snags, SVGs have a lot going for them. What accessibility issues have you noticed with SVGs? How did you solve the problems?  How are SVGs as a format better for you than traditional images in your designs? We’d love to hear about it in the comments below.

The post 7 solutions for creating more accessible SVGs appeared first on Simply Accessible.

]]> 2
How can I do this better? Tue, 14 Feb 2017 20:10:11 +0000 Nothing makes us happier than knowing there are people out there just as eager as we are when it comes to making the digital world better for everyone.

The post How can I do this better? appeared first on Simply Accessible.

Last week, we received this question through our website:

A developer sits working with his laptop at a coffeshopHello, I’m a front-end web developer in charge of accessibility in my company. I say that, but there’s never really any time for R&D, user testing is non-existent, and I basically try to bake it into my work following WAI-ARIA recommendations whenever I’m developing something not new (as opposed to retrofitting accessibility after an “audit”). Having seen some articles here, it has proven my concern that my guesswork does indeed have its limitations.

If I cannot do user testing and if I have limited time to “make” our UIs accessible, what can I do to do this better? Are there tools I can use? Experiences I can simulate?

Usually when we get emails at Simply Accessible, they are from companies looking to partner with us to help them make their digital products or services more accessible. Once in a while, though, we get questions and comments from individuals. Recently, we received the above question from a developer who is the sole person in their organization responsible for accessibility, with no budget or support for usability testing or research, and really no infrastructure for evaluating how effective their work on accessibility is. Outside the specifics of their situation, the question was one we’ve heard many times: “How can I do this better?”

Our hearts swelled. We put our heads together and wrote this response to the person we’ve affectionately come to call the Lonely Developer. It might help you, too.

Hi Lonely Developer,

First of all, kudos to you for thinking about accessibility as you do your development work! That’s a huge step in the right direction, and always smoother sailing than retrofitting.

Simply Accessible testers and developers came up with some ideas that might help you move things forward with your team. The biggest takeaway here is that there are many things you can do as a developer to make your product more accessible. There are also things you can do to help your team, and things your team can do to support you and each other, while you support your users.

As a developer, you can:

  • Embrace web standards and progressive enhancement. See what you can do with HTML/CSS/JS alone before relying on ARIA. There are often a few (or a dozen!) ways to implement the same content these days, but there’s still usually only a handful of methods that will work for literally everyone. Examine your features and go with the lowest common denominator option first (Is that element a decorative image? Then an old fashioned <img> is probably the way to go, versus a CSS content image that displays exactly the same way but doesn’t mean the same thing.).
  • Prioritize a few areas as you build for maximum impact on users. These are things you can test as you build and collaborate closely with design or UX to verify, and that will have a huge impact on the user experience for people that may have dexterity and mobility issues, low-vision, and cognitive-related disabilities. These things build on that HTML/CSS/JS/ARIA pyramid mentioned previously:
    • Test everything with the keyboard as you’re building, so you know it will be usable by sighted and non-sighted keyboard users.
    • Include text equivalents for all informative media (images, icons, charts, videos, audio, etc.). Also, make sure you’re implementing media in ways that won’t cause unexpected feedback for non-visual users. Remember that for many users the best way to convey information is in text, so they can process it in the way that works best for them, whether it’s through just skimming and reading with their eyes, through a screen reader, a text to speech engine, refreshable braille, or through a translation service into a different language.
    • Provide logical and clear forms with helpful labels, specific error messaging, and a clear path to correct problems. Forms can be challenging on a good day, so try to help your users have the best day when it comes to forms.
    • Check for color contrast with an online tool like Snook’s Colour Contrast Check. Users with low vision (as well as those in bad light or with tired eyes!) appreciate being able to read content without strain.
  • Turn on a screen reader, if you haven’t! We published a three-part series on integrating screen reader testing into the development process that might help integrate using a screen reader into your testing process.
  • Look into automated solutions for low-hanging fruit. Offload validation and binary testing that’s easy to automate onto a tool so you can focus on testing the user experience. A computer is more efficient than you are at finding misspelled or incorrectly used attributes, and you’re better at problem solving than a validation engine.
  • Check out pattern libraries like Integrate them into your own work and contribute. If your team has a pattern library, integrate shared patterns into your own library, development standards, and brand guidelines; if you don’t have a pattern library, standardizing your UI in the name of accessibility is a great reason to start one!
  • Have discussions with designers when potential issues appear in handoff, before development and, even better, before client or stakeholder sign-off. Getting accessibility integrated as early in the agile process (if you’re on an agile team) makes for fewer headaches later on.
  • Go to local developer or accessibility meetups and follow people in the industry on Twitter or other platforms. Even if you don’t have an accessibility meetup in your area, you can probably meet other developers interested in accessibility, who may be facing the same challenges you are. Together, you can create a support network.

As a member of your team, you can:

  • Work to educate the team around you about accessibility, including the leadership team. Getting the people above you and beside you on board can help make user testing and time for R&D more of a reality.
  • Encourage collaboration within your team so that accessibility is part of the entire process. Accessibility is not an engineering problem–it’s a human interaction problem. Making one person responsible for it doesn’t scale.
  • Organize accessibility learning sessions with team members. These don’t have to be long or elaborate. For example, take an hour or so over lunch to talk about keyboard accessibility; go through one of your products with the keyboard alone, as a group. Seeing a potential problem firsthand goes a long way toward helping designers, product owners, and other stakeholders understand accessibility in context.
  • Find allies in your organization. Use those learning sessions and collaborative exercises to find other people who are interested and invested in accessibility. Those allies may be in places you don’t expect, and may be on teams you don’t normally work with.
  • Talk to your product owner or project manager about including people with disabilities in your QA cycle. Short, paid studies to look at specific, high-value activities with a handful of people with disabilities can go a long way toward gut-checking your work and making improvements that benefit everyone. Find local advocacy organizations for people with disabilities if you’re not sure how to contact potential participants.
  • Consider ways to create a more inclusive work space and encourage hiring with diversity in mind. This isn’t something you can do alone, but taking inclusivity to heart helps organizations put accessibility work into context.

Don’t give up! It can feel frustrating at times and the accessibility learning curve has a lot of friction. You aren’t alone in this, even if it feels like you are sometimes. We hope some of these suggestions will help you feel like you’re a member of the accessibility family (because you are). Your users (and we!) thank you.

What tip do you find most helpful? Have you discovered any other ways to be successful within your organization? We’d love to hear about it in the comments below.

The post How can I do this better? appeared first on Simply Accessible.

8 things parenting taught me about accessibility Thu, 26 Jan 2017 20:40:41 +0000 Parenting presents all kinds of challenges, even technical ones. In this post, Melanie Jones shares how vital her mobile device became once she had a baby, and how inclusive design makes all the difference.

The post 8 things parenting taught me about accessibility appeared first on Simply Accessible.

I had a baby five months ago. It changed pretty much every aspect of my life, including how I interact with the web. I used to spend all day luxuriating on my laptop, feet up, tabs open all over the place, a cup of actually hot tea in my hand.

Now? My tea is lukewarm on a good day and my smartphone is my everything.

Often my only connection to the world outside my apartment, I use mobile for all my online interactions. I Google weird baby behaviour seventeen times per day. I stay in touch with my friends, send adorable baby pics to grandparents, and organize walks with other mamas. I shop for groceries and baby gear. I transfer funds and make doctor appointments. I sign petitions and email congresspeople. My social life, work, research, commerce, and activism all happen on my mobile device.

I got us a new apartment via my phone. I looked at floor plans, negotiated the lease, signed documents, and scheduled our move-in, all from my phone. Same with a lactation consultant session; I booked the appointment by text message, did the session via FaceTime, and paid her from a mobile app. (I did most of that topless, too.)

I’m typing this article with one finger as my kid naps next to me.

This new dependency on my mobile device has shed a whole new light on what accessibility means to me. Here’s what I’ve learned:

1. Usability is everything: A spectacularly simple and usable mobile site or app is critical for me. I don’t have time to go get my laptop, open it up, and use a site. I need the site to come to me, and I need it to know my next interaction before I do. My phone is always with me and I’m always with the baby. I need websites and apps to be actual no-brainers to use because my mind isn’t on them—it’s on the seven-limbed creature flailing in my lap.

2. One-finger and within-thumbs-reach computing: I’m usually using one hand, frequently my non-dominant one. I need interactions to be dead simple and easy for me to complete—especially because my device is slightly too big for my hand. I’m not sure whose hand this thing was designed for, but my thumb is exhausted from reaching for that ‘a’ key way over there and trying to get the right combination of emojis to express my complex experience. (It’s heart eyes/sob/smiling pile of poop.) I’d love if you could tell me how to get an infant to nap longer than 45 minutes, but honestly, I’ll settle for a hamburger menu I can reach.

3. Forms need to be wildly easy to complete: I rely hugely on autocorrect, sites that remember my shipping or billing details, and auto-filled email addresses. My heart swells with joy when a site defaults to a number menu for a zip code or a phone number. I need workflows to be intuitive and efficient—anticipating my needs and helping me reach my goals quickly. Every step of the process needs to move me forward, not get in my way, and I need it to be really easy for me to fix my bleary-eyed mistakes. A clear, usable form literally makes my day.

Here’s what I bring to the table: a valid credit card, 90 seconds of my time, and my right thumb. The rest is up to you.

4. Make your content awesome, so I don’t have to be: I’m nearsighted and I just turned 40, so the other end of my vision is starting to go, too. I could jack up my font, but I literally don’t have time to wade through the settings menu. I’m probably squinting at a site at 4 am, hoping the headings and navigation are crystal clear, and that the first paragraph of text tells me no poop in five days is perfectly normal and I’m doing a great job.

5. Deliver on your promises: If you’re an app that lets me order groceries and you tell me I can interact with the shopper, I need to be able to interact with the shopper. My meals have become masterpieces of efficiency…if I get exactly what I need. One app I used had a field where I could message the shopper, but no one ever got back to me. The shopper was also supposed to text me with any substitutions they made in the store, but it never happened. I’d just have to hope for the best and ask for refunds on mistakes. It was a pain for me (once I ended up with two litres of maple syrup!) and costly for the folks who run the business. I need to trust sites and apps and rely on them to hold up their end of the deal.

6. God help you if that video autoplays and wakes up my kid: I will find you.

7. Create a predictable user experience: I use a white noise app to help the baby fall asleep, but I usually need to do other stuff on my phone while I wait for her to doze off. Whenever I leave the app, the waves stop and the sudden silence often wakes the wee one up—the opposite of the app’s intention. Most audio-centric apps I use (phone, music, Spotify, etc.) play their audio in the background while I use other apps on my device. I’ve come to expect audio to continue playing when I switch to other apps, so it’s frustrating when this one hijacks my phone.

8. Clear before clever: I have this app that tracks my baby’s developmental leaps. It has a calendar function to tell me when a leap is coming and lots of rich content to teach me how to support these often tumultuous periods of growth. Only trouble is, I can’t decipher the calendar to save my life and each section of content uses an “adorable” icon that baffles me. The app also has a leap alert that’s supposed to send me an email when a leap is about to start, but it doesn’t seem to work at all, in spite of its very attractive toggle switch. The graphic design keeps me from getting crucial information. I’m all full up on cute in my life—clarity’s what I need.

While parenting isn’t a disability, it has definitely upped the stakes on my mobile computing. I have a lot riding on that 4” screen. Even though I’ve been on the Simply Accessible team for more than two years, the last few months have brought home the importance of what we’re doing here.

Inclusive design and a great user experience used to be luxuries for me—now I understand how essential they are, especially for folks whose abilities and capacity are different from mine. Users really are relying on you and your team to create sites and apps that make their lives easier.

Check out Devon’s article and tutorial on keyboard support for mobile to dig into the nitty gritty of making your sites and apps easier to use—and please tell us about your favourite, usable mobile apps in the comments below!

The post 8 things parenting taught me about accessibility appeared first on Simply Accessible.

We’re going on a bear hunt: the prologue Tue, 17 Jan 2017 05:00:28 +0000 Fear and worry are often companions as we journey towards accessibility. Elle Waters reminds us that in order to build successful accessibility programs we need to face our fears, not ignore them.

The post We’re going on a bear hunt: the prologue appeared first on Simply Accessible.

The best way out is always through.

– Robert Frost

Whenever I lead a workshop, I like to start things off with fear.

After welcoming people to the room, I ask everyone to answer this question: “When trying to build an accessibility program, what’s your biggest worry about being successful?” As people volunteer to share their personal anxieties to the group, I put the big list onto the big screen, and we talk through each one.

As shy nervousness inevitably gives way to raw frustration with each admission of the struggle, I often feel like I’m actually here to host a support group. It’s permission to complain, to vent…to rant, even, about fulfilling this idealistic dream of making digital experiences for everyone actually sustainable. Interestingly enough, expressing shared anxieties about building an inclusive world does a lot for people. In my experience, accessibility program workshop attendees, often solo champions, are a little weary and isolated.

Last year, we ran a poll on the Simply Accessible homepage over a period of several months, asking our readers a single question: “What’s holding you back?” And, you know what? The answers we received were almost identical to those shared in workshops.

Instead of pretending like those fears don’t exist as everyday reminders of our possible failure in this profession, I like to get them all out there. These kinds of worries are impossible to ignore. By facing them openly, we create real solutions to problems we will face today and the very next day. A simple but powerful principle that I learned from a children’s book.

When I was growing up, we had a tradition in my rather large family where older siblings would read a book aloud to the younger ones each night for bedtime. As the loud one in the family, that duty often fell to me. So, I carried the practice forward with my own son when he was young. One of his favourite books for me to read aloud to him was We’re Going on a Bear Hunt by Michael Rosen. I suspect he liked the delightful illustrations by Helen Oxenbury and the repetitive, chant-like sounds that the narrator used to describe each challenge the characters faced. But this fall, when cleaning out my son’s bookcase for his move to college, I found the book and was struck by how much wisdom it contained.

The story begins with a family stepping outside and boldly proclaiming their intentions.

We’re going on a bear hunt. We’re going to catch a big one. What a beautiful day! We’re not scared. 

How true this rings! This bold proclamation sounds a lot like the passion many of us feel when we decide to go on this accessibility journey, when we first really “get it”—that moment when the mission of inclusion clicks and we understand our place in it.

The family in the book then encounters a series of obstacles, each one unavoidable. The narrator describes each one in tangible detail.

Uh-oh! Grass! Long wavy grass. 

Together, the family repeats the same refrain…

We can’t go over it. We can’t go under it. Oh no!  We’ve got to go through it! 

And they do.

Swishy swashy! Swishy swashy! Swishy swashy! 

All too often in accessibility, we avoid doing what lies before us because it seems impossible. What’s our long, wavy grass? Here are some worries that may sound very familiar to you: We can’t change this legacy platform—everyone at the company relies on it. Or, we can’t get leadership to support accessibility initiatives when they just cut the design budget. Or, there’s so much work to do, and accessibility won’t succeed, because I’m all alone here.

Sometimes, we try to convince ourselves that we can go around the obstacle, deferring the needful to avoid the pain. Maybe if we just run an automated scan. Or maybe if we don’t object when it’s clear that the development team thinks of accessibility as a “bug list” to meet minimal compliance requirements, we’ll at least make some progress. And we make incremental improvements that make us feel a little better. But it’s not transformative. And we know it’s not. The problems still exist.

As accessibility advocates, we often believe more in the obstacles we face than in our own shared expertise as a community.

So, what are those fears that people have when trying to build a successful accessibility program?  What’s really holding you back?

In the following months, we’ll go on a bear hunt. Together, we’ll focus on several topics that hinder the progress of accessibility. Things you’ve shared in workshops and in our website poll. We won’t go over them, we won’t go under them—we’ll go through them. Together.

The post We’re going on a bear hunt: the prologue appeared first on Simply Accessible.

Show up Tue, 10 Jan 2017 23:02:51 +0000 As we launch into 2017, begin with the end in mind. Where will you be in December? What will you have accomplished?

The post Show up appeared first on Simply Accessible.

With the spirit of the new year fresh on your mind, you imagine yourself, almost a year into the future… It’s the end of 2017 and you’re on top of the world.

Why? You rocked 2017 in terms of accessibility and inclusion. Your site and your systems are humming along, more accessible than ever, and you did it in just under a year. Everyone keeps saying it was like rocket fuel, and they still don’t understand how you were able to do so much in just 11 months.

Think about that for a moment. You really did it.

You got the support you needed at every level. Your leadership team called out diversity and inclusion at their annual shareholder meeting (that was amazing!), and even those old school IT managers started attending sprint planning sessions and demos to show their support. Your designers and developers started sharing the things they learned in each sprint with all the other teams, and even put together open lunchtime sessions to help teach the rest of the company how to start thinking more inclusively in their work. Sure, there were times when there was unrest (more likely felt like it was bordering on upheaval, am I right?) but you stuck it out through the difficult times and it made you stronger.

Your devs said that their defining moment in 2017 was when they saw the accessibility issues that we logged in two different ways: yes, there were 173 problems that had to be fixed in that mobile app you just rolled out (boo). But, as part of the bigger picture, each of those 173 issues showed you a hole in your learning process as a team. It was that moment when they knew that fixing all the “accessibility bugs” would be wasted effort if you didn’t prevent them from happening again. The best part was when the team who fixed the issues put together a deep tutorial on “how to do it right.” Three months later, that new team of product managers, designers, developers and QA staff that joined you, said “Thank you SO much for being there for us… you saved us 12 weeks of work!”

The epiphany

In June, your BAs, Product Owners and Product Management team had that slightly painful epiphany when they saw that it was literally impossible to list all the accessibility requirements for an individual story. Remember when your brightest PM stood up in the middle of the work day and kind of freaked out? “There’s over 200 accessibility things we need to do with this one screen alone!” and later, when trying to solve the problem, she complained, “if we listed them ALL, the story itself would be so large it’d be impossible to close!” Your team got to work, broke things down, and figured out what requirements to put where in the project lifecycle.

Once they really understood their role in building inclusive interactions, your designers looked like they were given an early holiday. They were so on board — they talked with each other more than ever before. They talked with the engineering teams… in ADVANCE of starting the project. They even made you an honourary unicorn badge for all your help last year.

Everyone is pointing to all the success stories that made this such an incredible year for accessibility, but no one is looking at the one game changing thing that you did to make it work. How did all this happen? There’s a lot of detail that went into it, but here’s the bottom line.

You showed up.

Yes, it’s that simple. You showed up. Even with the extra workload and added pressure you felt, you were SO much more than a warm body. Those meetings that were scheduled with that consulting team? Not only were you there, but you came prepared with thoughtful questions. When others were talking about something that wasn’t directly related to you, you didn’t tune out and check your email on your phone. You did the opposite — you tuned in and looked for a connection to your work, an opportunity to represent accessibility as a solution to their different challenges.

You knew accessibility would be a challenge… but a worthy one rather than an onerous one. You saw the importance of the work, and you didn’t try to sweep it under the carpet. You didn’t go hunting for shortcuts. You didn’t let that little voice in your head ask “what’s the minimum I have to do to make this go away?” Instead, you heard the call: “How can I help others here believe in this as much as me?” You heard it proclaim: “Let’s do this!” And you didn’t do this alone. Your team couldn’t have done all of this without you in 2017, but they succeeded because you contributed the most important thing first: yourself. None of the techniques, criteria, or test cases will ever compare to your support and commitment.

Because you know… you could battle and do all of this with long nights and tireless days of pushing others into the work. But accessibility isn’t going away — it’s a way of thinking, a compassionate and inclusive way of thinking about everyone, and when you work like that, you pull people in. And here, at the turn of a new year, you’ve realized this is how you wish you had been working all along.

Show up.

The post Show up appeared first on Simply Accessible.

Team Retrospective: 2016 Thu, 15 Dec 2016 21:44:25 +0000 As 2016 draws to a close, we asked members of the Simply Accessible team to reflect on the most impactful changes they saw clients make this year.

The post Team Retrospective: 2016 appeared first on Simply Accessible.

For better or for worse, 2016 has been a landmark year for the world. No other year has seen humanity dance so tenuously between division and connection. It has been a year of being confronted again and again by the news and being invited to respond, and respond differently than we may have in the past. In the public arena, and in our personal lives, 2016 was a year of challenge and choice.

2016: a year of learning and growth

How did this year impact us in our work? Here at Simply Accessible, we also saw major shifts and changes, within not only our own work but the attitudes and approaches of our clients. Equal parts inspiring and overwhelming, there’s no denying that 2016 was a year of steep learning, evolution and growth for all of us, our clients especially.

As we wind down 2016, we asked some of our team members to comment on the most significant changes they saw our clients make this year that had the greatest impact on their site users. Here’s what they had to say:

Gavin OgstonGavin Ogston, Accessibility Specialist:

I think 2016 was a landmark year for many of our clients who have been struggling to gradually increase their knowledge of web accessibility. What we saw this year for many clients was that they discovered how they could go beyond the basics and began to talk about how they can deliver the “best” experience for their users.  As a company that’s always trying to promote the creation of a user experience that is not only inclusive, but goes beyond that to be delightful for everyone, I feel 2016 was one of our best years yet.

Devon PersingDevon Persing, Accessibility Specialist:

This was a year for companies to consider how their mission statements for inclusivity and diversity really affect their customers. With the Department Of Transportation’s updated requirements for air carrier accessibility, 2016 marked the first time an entire private industry in the United States was regulated to meet a standard for digital accessibility. The ripple effect is already being felt in other parts of the travel industry, and it’s just the beginning!

Caryn PagelCaryn Pagel, Accessibility Specialist:

I saw one of our clients completely change their mindset this year. When I started working with this client, they were in “get it done” mode. As we progressed through the project, and they began learning more about why web accessibility is so important, it was exciting to see them shift into “let’s do this the right way” mode. They started thinking of how to incorporate accessibility into their design and development cycles, and how simple tasks could affect ALL their website visitors. It’s been incredibly inspiring to see a team that once knew little about accessibility blossom into the advocates they’ve become.

Jeff SmithJeff Smith, Director of Operations:

One of the most impactful changes I noticed our clients making in 2016 was taking usability testing results that we provide to heart and looking at those results being as important, if not more important than assessment or “audit” results. 2016 noted a very significant shift in the mindset of our clients to one of caring about actual users’ experience and the roadblocks that people with disabilities face on a daily basis on the web. It’s been incredibly refreshing to have our clients really start to consider their end customers and how the work they’re doing impacts them. My hope for 2017 is that this trend continues and that we see even more clients coming to us for the first time that already have their customer’s needs as the driver of their accessibility efforts.

Kara VanRoekelKara Van Roekel, Accessibility Specialist:

I saw a client move from being slightly skeptical of the accessibility testing we were doing and recommendations that we were making, to actively soliciting feedback and comments on planned updates and design changes. They went from dubious to eagerly wanting to ensure that they developed their products in an accessible manner the first time around. That made me really happy… knowing that we helped to convert someone to being conscious of the needs of disabled users.

We’re going to need a bigger boat

Fundamental to the work we do at Simply Accessible is empathy and the desire to make the digital world better for everyone. 2016 showed us that our clients are starting to get in the boat with us, and users everywhere will benefit from these mindset shifts.

What were some impactful changes you made in your own accessibility practice or experience in 2016? We’d love to hear about these in the comments below!

The post Team Retrospective: 2016 appeared first on Simply Accessible.

Shifting perceptions: reflections on the International Day of Persons with Disabilities Thu, 08 Dec 2016 19:41:42 +0000 December 3 marked the International Day of Persons with Disabilities (IDPD). SA tester and team member, Rhea Guntalilib, considers what the day means to her.

The post Shifting perceptions: reflections on the International Day of Persons with Disabilities appeared first on Simply Accessible.

As I reflect on the International Day of Persons with Disabilities (IDPD), I’m reminded that I’ve only been in this demographic for 10 years of my life so far. But what a decade it’s been!

I was perfectly sighted for the first 18 years of my life. When I was diagnosed with typhoid fever, however, it was clear my symptoms went beyond those that were typical of the illness. Within two years, I lost my sight completely.

I was devastated.

I can’t deny that it was horrible, truly. However, it wasn’t long before I realized that I had no choice but to pick myself up and move on. In doing so, I truly gained my life.

I may have had sight until I was 18, but I had no direction in my life. I had no clarity, no purpose. I believe fully that it was through the loss of sight that I finally found my vision.

The International Day of Persons with Disabilities is an observance begun by the UN in 1998. It’s an important day to me not only because I fall into this category by definition, but also because it was the journey to accepting my blindness that motivated me to advocate for others like me.

Here I am, 10 years after becoming blind, working with Simply Accessible and contributing every day to making the digital world more accessible for people with disabilities. I’m grateful to be a part of the team at Simply Accessible, and while I see the headway we’re making, I’m also aware that we’re still only part of the solution.

It’s time that the perception of people with disabilities as a liability to the community changes or disappears altogether.

It would be a dream come true for me to witness the whole world completely embracing our unique abilities. A world with equal job opportunities for all. A world where our capabilities are not measured by our physical limitations.

I’m passionate about helping web professionals understand how people with disabilities use technology. Many developers just don’t even realize it’s possible for a blind person to use a computer—which means they aren’t considering accessibility features when they’re developing. Accessible design helps me and millions of other people in all of our day-to-day activities, like online shopping, and banking. Not only that, accessible design helps me and others like me do our jobs and contribute to society through the work we do. Accessibility allows people with disabilities to contribute in all kinds of ways—it impacts our lives every single day.

For my part, I’m eager to continue making the web a more accessible place. It’s going to be a long road, but I believe that we’ll get there eventually. Technology like screen readers is now considered a necessity for all kinds of users, so being inclusive in design and development really does benefit everyone, not just persons with disabilities.

The theme for this year’s IDPD is “Achieving 17 goals for the future you want.” While I don’t have 17 goals of my own, my number one focus is helping others in the future by setting an example for people with disabilities. I’m a passionate advocate for digital accessibility, always striving to help people realize the power that we have in changing our lives through accessibility. It’s time to change the face of the digital world, and I believe the best way to do this will be for the digital sector to work hand in hand with persons with disabilities. Let’s make the online world better for everyone.

The post Shifting perceptions: reflections on the International Day of Persons with Disabilities appeared first on Simply Accessible.

]]> 2
Starting the conversation: report from Accessibility Scotland Thu, 01 Dec 2016 20:39:28 +0000 When Kevin White found himself longing for people to talk with about the challenges of accessibility work, he didn’t just go online and join a meetup group; he decided to organize a conference with his peers. Here is Kevin’s report on the first-ever Accessibility Scotland conference, held last September in Edinburgh.

The post Starting the conversation: report from Accessibility Scotland appeared first on Simply Accessible.

Putting out the call

A photo of Edinburgh castleScotland has a thriving web community built on great developers, designers, testers, and UXers. I have been part of this community for more than ten years, during which time I have regularly attended various meetups and conferences to discuss all things webby. One thing I always wanted to experience in Scotland, however, was a conference that was solely focused on accessibility.

I will admit to being selfish; I wanted to meet people interested in the same things I was and, more specifically, facing the same problems I was. As a UXer trying to help organizations make accessible websites, far too often I would be engaged at the validation stage, the end of a project, only to find that organizational awareness of accessibility was not what I might have hoped for. I’d seen too many organizations thinking they didn’t need help, or putting a bandaid on the situation too late to make a difference. It wasn’t the problems that bothered me so much as it was the lack of community around me to hash these things out with, or start the conversations I had been craving.

I wondered if there were people out there who were thinking, like I was, “Is there a different way to do this?”

The years rolled by and I bumped into more folks of a similar mind. Then last year three of us – David Sloan, Wojtek Kutyala, and myself – decided that if no one else was going to organise something then we would. Oh dear.

Accessibility Scotland is born

The upshot of a lot of work (mostly by folks other than myself) was Accessibility Scotland. On the 16th September, 70-odd bleary-eyed developers, designers, testers, project managers, and others turned up at Codebase in Summerhall, Edinburgh, lured by promises of coffee and accessibility goodness. While the coffee supplies dwindled, the accessibility goodness flowed out in abundance.

Out of all the conversations I had on the day, one that stood out the most was after the event. I was chatting with some attendees who were nearing the end of a vocational course in web development they had taken. The talks they’d just heard at Accessibility Scotland had revealed to them something completely new and important. Despite the great feedback we received from attendees, including from these students, I couldn’t help feel sad that all the work they had done on their course hadn’t touched on accessibility at all. If they had not gotten themselves to AS that day, they would have entered the field with great digital skills but no understanding of how using those skills could empower people with disabilities.

Time for a new approach

For all the vibrancy, energy, and intelligence in Scotland, we still fail far too often to ensure that we are making a world that is open and welcoming to all, regardless of ability or disability. More often than not, when I am brought in to evaluate sites or apps, there are basic errors that simply shouldn’t occur. And that bugs me. It bugs me because I feel that accessibility should be part of the core disciplines for people who create digital stuff.

In the scheme of things, and this might be doing me out of a job, this stuff isn’t hard. Not compared to the bazillion other business and user requirements that are regularly thrown at project teams. I grant you, there are challenges, especially when your new designer has decided that what would really make this site stand out is a clickable haggis bouncing across the bottom of the screen as the only way to access the application form (a fictional example, of course).

Where I think we are failing most is that we are teaching accessibility in the same way that many approach accessibility – as a bolt-on; an afterthought.

This needs to change; and, while change does not just come from more educational conferences, I’m certain that Accessibility Scotland introduced change to a few minds that day. We need to bake this into the education and training of the new generation of digital professionals in a way that makes a difference. For example, accessibility should be a testable component of submitted work. A key part of this is connecting the technical knowledge to the experiences of real people and cultivating recognition of how high-quality, accessible content has a positive impact on lives. Developing a sense of empathy in digital professionals won’t solve all the problems, but it could give us more people who can and will raise questions about how their creations are experienced by people with disabilities.

When we had our planning meetings for Accessibility Scotland we knew that what we wanted most to create was the space for these discussions to happen and that empathy to develop. In some cases, the space to even start this conversation. I knew most of the audience who would be attending, and I knew they were already versed in accessibility, but I also knew there was more to be talked about.

Expanding the horizons

At the end of the event, countless feedback forms all said the same thing: Please do it again. It was a lot of work and a lot of stress to put it on, so it was rewarding to know that people appreciated it and are hungry for more.

To me, conferences are for expanding boundaries, pushing the edge of our knowledge, exploring the horizons of what’s possible. We didn’t quite get there at the first Accessibility Scotland, but we’re on our way. In the process of thinking about Accessibility Scotland 2017, we are looking at adding a training feature to the event. We want to take the talented community of Scotland’s designers and developers and keep them in the conversation of how to design in a way that keeps people with disabilities in mind. That’s designing holistically.

One of the most profound talks of the day served as a brilliant reminder of how imperfect accessibility is. We live in an imperfect world. In some ways, it’s quite refreshing to be reminded that we’re not going to get it right all the time. Things will go wrong, we’ll miss stuff, but we’ll keep listening and doing the best we can.

The post Starting the conversation: report from Accessibility Scotland appeared first on Simply Accessible.

Listening to the web, part three: working with screen readers Thu, 17 Nov 2016 19:02:05 +0000 In the previous article, we unveiled the magic behind semantic code and using native elements in designing usable sites. Remembering to keep a mindset of accessibility and inclusivity, we journey onward in the third and final article in this series. Destination: screen readers. You’ll come away with everything you need to know to get your hands dirty when it comes to designing, developing for, and testing your sites with screen readers.

The post Listening to the web, part three: working with screen readers appeared first on Simply Accessible.


Article Series:

Now that we have learned about the importance of thinking in accessibility, and using native elements when it comes to designing sites that are usable, let’s turn our attention towards learning about screen readers.

As I began to work with screen readers, it was sheer curiosity that propelled me to dive in fearlessly. I knew it was something I wanted to learn, so I rolled up my sleeves and got to work. In this post, I will share with you the basics of screen readers: how they are used and commands to know. I’ve included a demo to show a few common problems with solutions as you’re getting started.

Keep in mind, any journey involving learning is ongoing. Let your accessible and inclusive mindset form a solid foundation upon which you can add new knowledge.

How people use screen readers

I took a Communications class in high school, and during each class we were encouraged to read the newspaper as a way of staying up to date on current events. We were taught a handy technique while reading the paper, which was to quickly scan each headline of the top stories. If something stuck out as interesting, we could make a mental note and return to read the story after scanning the rest of the newspaper headings.

In the same manner, people who use screen readers are able to scan through and read the headings of a web page (I’ll show you how you can do this too, later in the article.) This is a great way to quickly gain an understanding of the content available on the page and whether it’s something of interest and worth returning to.

For this very reason, it’s vital to make sure heading elements are present and structured in a logical order. Start with one h1 which would describe the overall purpose for the page, the main “headline.” This would be followed by subsections of content using h2 elements, and perhaps a subsection of that section, using an h3, and so on. Tip! Don’t use a heading element purely for the stylistic effect. If you need a heading to look a specific way, add a class attribute and use CSS to make it look how you need. Also, keep in mind that the visual appearance of headings is important, since it helps people who have difficulty reading or who have other cognitive issues gain an understanding of the page structure as well.

People using screen readers can also quickly scan the page for content by using links. Screen readers often feature a way to navigate site content by announcing each link on the page, in a list format. People can decide on whether they’d like to follow the link or not, based on the link text. For this reason, it is crucial that link text is both unique and descriptive. It can become a frustrating user experience when all the links on a page are announced as “Read More” and no extra context is given as to where the link leads.

You can also simply use the Tab key to move around and discover interactive content. This is a common method of navigation and gaining an understanding of the page, but it’s not quite as fast as navigating by element type and only accesses elements that are focusable.

And what about non-focusable elements, you may ask? Don’t fret, I’ll show you how to access things like plain text and images in the next section!

Let’s look at a few screen reader commands in more depth.

Screen reader commands devs should know

If you’re on an Apple desktop or laptop (or even mobile device), you’ve got a screen reader called VoiceOver right at your fingertips. If you’re using Windows, there’s a free, open source  screen reader called NVDA available to install. Tip! Pair up VoiceOver with Safari and NVDA with Firefox. These are the most commonly used browsers with these screen readers.

To start VoiceOver (VO), press the Cmd + F5 keys. VO will start reading the page or application you’re currently looking at. You can Cmd + F5 again to quit out of VO.

Start NVDA by pressing Ctrl + Alt + N. Alternatively you can use the Windows Run dialog and enter, “nvda”. One method to quit out of NVDA is to use the Run dialog again and enter “nvda -q”.

Use your computer’s volume control to adjust the voice volume as needed.

Modifier keys

Modifier keys are screen reader specific shortcut keys. They are used with other keys on the keyboard to execute various instructions to the screen reader.

The modifier key for VO is Ctrl + Opt. For NVDA, by default, the modifier key is Insert. This can be changed in the configuration to be Caps lock if you’re on a laptop.

For example, to start reading a web page using NVDA, you could press Insert + Down arrow and NVDA will begin to read from the current position.

Tabbing around

When you have either VO or NVDA enabled, use the Tab key to move in a forward direction through interactive elements on the page or Shift + Tab to move backward. Depending on your browser settings, by default, elements on the page that you can tab to would be things like links, buttons, or form controls. Moving around in this fashion is considered using the “browser cursor.” The browser cursor moves focus around from one focusable element to the next. While this is quite handy for keyboard-only users, there is another cursor which can move to non-focusable items and describes the content on the page with greater detail, the “screen reader cursor.”

Screen reader cursor

VO and NVDA have their own built-in cursors which people can use to move around the page and read other content, not just focusable items.

To use the VO cursor, hold down Ctrl + Opt, then use the Left or Right arrow keys to move around and have VO announce all types of content on the page. NVDA’s cursor is moved about by using the Up and Down arrow keys. This reads one line of content at a time.

Reading the page in this manner reveals more page content, including plain text, image alt-text, and page headings. This is a great way to test and hear how text content sounds, and if descriptive image alternative text makes sense with what’s being displayed in the image.

Advanced navigation

Both VO and NVDA offer a way to navigate page content by grouping like elements together. Each screen reader is able to display a list or menu of like items, separated by categories, in order to quickly move around the current page and easily discover what content is available.

VO Rotor

The VO Rotor is essentially a menu of different types of elements on the page, broken down into categories. To open the Rotor, hold down Ctrl + Opt then press the U key. A new VO window will appear overtop of the page with a list of items.

When the Rotor is open and available for navigation, use the Left and Right arrow keys to move between element categories such as headings, links, landmarks, or form controls. Use the Up and Down arrow keys to navigate through the listed items. Use the Esc key to exit out from the Rotor.

NVDA Element List

NVDA also has a menu of elements on the page called the Element List. To open the list, use the Insert + f7 keys.

When the Elements List is open, use the Left and Right arrow keys to move through the types of elements. Press the Tab key to move down into the list. Once in the list, use the Up and Down keys to move through the list items.

There are many more shortcuts and keystrokes available for these screen readers, but these are just a few easy ones to learn to help you get started.

Next we’ll take a look at a demo site and use VoiceOver to navigate through the page elements, searching for potential accessibility issues.


Let’s look at a before and after example of a demo site. It’s important to remember: when investigating issues, always check first to see if you’ve used the right elements as they were meant to be used. Often, there’s no need to create a complex solution to fix a problem when a more semantically structured solution will do the trick.

In the two demo sites linked below, you will notice that the example pages look the same, but the code underneath is quite different. If you were to use your mouse to navigate around and submit the form, they work perfectly well just the same. However, what happens when someone using a screen reader or the keyboard alone navigates the page and tries to fill out the form?

Listen to the following video as I use VoiceOver to navigate through the page elements. What do you notice?

(Try it yourself! Open Demo 1 on Codepen)

It looks like the screen reader got hung up on a few things:

  • When the logo link image received focus, it didn’t sound like descriptive information. What was it supposed to represent?
  • Did you notice the navigation links were skipped entirely? What happened there?
  • Each form input was announced as such, but what were they for? What type of data was expected?
  • The form submit button seemed to have been skipped as well? How could someone submit this form using just a keyboard?

Let’s address these issues and see what went wrong.

Target Element Problem Solution
Logo Link When the logo link received focus, the embedded image alt attribute text was announced. In this case, since there was no alt attribute present, the image file name was announced. This can easily be remedied by adding an appropriate image alt text value. In this instance, it should match the text of the image itself.
Navigation Links When we inspect the markup for the navigation links, we see there is a custom JavaScript onclick event and no href attribute. Links without the href attribute will not receive keyboard focus which is why they were skipped. We can fix this quite easily by adding an href attribute for each link, adding the appropriate page URL as the value, and removing the custom JavaScript onclick event as this is no longer required.
Form Inputs The form input elements gave no context for their intended purpose or expected data. This is a result of the inputs not having an associated label to help explain the purpose of the control. We need to add a label element and set its for attribute to match the value of the id attribute of the input. Now when the element receives focus, its label will be announced alongside the element role.
Submit Button The submit button was skipped because, well, it’s not a button at all. The element is actually a span with a custom JavaScript onclick event and CSS styles to make it appear as a button. We can easily make this element keyboard accessible by changing the span into a button element. With this change, the button will be focusable and announce its role as “button,” which indicates that the Space key can be used to submit the form.

After fixing these issues, let’s listen to the page again and see what things sounds like.

(Try it yourself! Open Demo 2 on Codepen)

After listening through the page again, we gain a much clearer idea of the content. The main logo image has an alt attribute which announces the text embedded within the image. Each of the main navigation links are able to receive focus and are announced as a link element. Each form input is announced along with its label, revealing what type of content is expected. The form submit button is announced as such, receiving focus and fully supporting the keyboard interactions available to a button element (Space or Enter key presses.)

There were also a few additional adjustments made to add even more semantic meaning to the elements on the page:

  • The header, nav, and main HTML elements were added as wrappers for their respective content. These create “landmarks” within the page. Someone using a screen reader could now have the option to navigate by landmarks, as well as headings and links, etc, when using the VO Rotor or other shortcut keys.
  • A ul list element was used to give extra context and structure to the navigation area. This helps to give notice on how many links are present when entering the list, as opposed to someone having to tab through each link to gain this understanding.
  • The main title of the page is now wrapped with an h1 element, allowing for heading navigation and to give notice to the overall purpose of the page. Another optional attribute added to this element was tabindex. Giving this attribute a value of 0 adds the element to the natural browser tab order, which means this element will receive focus and be announced by the screen reader.

Testing with a screen reader (and tabbing through your pages using only a keyboard) by following the browser or screen reader cursors and attempting to complete tasks with just a keyboard will tell you a lot about how accessible your code is and whether it will make sense for people using assistive technology. If something doesn’t sound quite right or is unreachable, there are issues that need to be addressed before shipping to a production environment. As mentioned earlier, screen reader compatibility isn’t synonymous with full accessibility (there are a lot of other considerations for other types of users), but creating semantically structured code that’s fully accessible to a keyboard goes a long way in helping both sighted and non-sighted keyboard users.

Start with accessibility in mind. Test with various screen reader + browser combinations. Test early and test often. Be sure not to add accessibility on as a feature after launch as this rarely works out in the end, and people will notice.

With great power…

I’ve given you enough to get started with how screen readers are used and how you can test your pages with screen readers, but I’d be remiss if I didn’t leave you with possibly the most important thing to know about accessibility development: screen readers are just the beginning.

Even on our own team, screen readers are where some of us started our accessibility journey. Developers are fascinated by the technology and it’s the first thing we get into. Still, learning to use and test with them really is just a start. It’s the first point on a much longer journey that includes considering the wide range of people’s abilities, situations, and all kinds of use cases.

I hope this series on “Listening to the Web” has inspired you to make positive changes in your daily workflow. I urge you, fellow web developer, to take the plunge and dive deeper into web accessibility. Learn all you can, and share what you’re learning. Get feedback and support from the greater web community. Put in the extra effort, even when not budgeted for. Eventually, it won’t be extra effort at all but simply part of your daily workflow. One person can make a difference.

Start with accessibility in mind, listen to the web, and make awesome things for everyone.

The post Listening to the web, part three: working with screen readers appeared first on Simply Accessible.

Listening to the web, part two: it’s all semantics Wed, 16 Nov 2016 18:38:58 +0000 Building upon our accessibility mindset, in this part of Scott Vinkle’s three-part series we journey into the land of accessible code. We cover the basics of writing semantic HTML, and we explore why native HTML elements are so effective in creating highly user-friendly websites.

The post Listening to the web, part two: it’s all semantics appeared first on Simply Accessible.


Article Series:

As designers and developers, at the end of the day, we do what we do because we want people to benefit. As we discussed in yesterday’s post, it’s essential that we consider the various ways others might be interacting with our sites. Are they sitting comfortably in their home on a laptop? Do they have an infant in one arm and a phone in the other? Are they in a rush trying to find information on the closest hospital? The fact of the matter is, we can’t know.

We will never know when, why and, in some cases, how someone will interact with and consume the content we put out into the world. What we can do is realize this fact, embrace uncertainty, and try to create functional user interfaces for as many contexts as possible.

I believe one of the best ways to achieve this feat is to ensure accessibility is at the forefront of the design and development workflow.

Use semantic HTML

In my early days of working with the web, I heard the term “semantic HTML” and how it was the “correct” way to write HTML markup. Every time I heard that phrase, I really didn’t understand what it meant. For a long time I thought the idea was to make sure you wrote valid HTML and tested its validity by running your source code through the W3C validator.

I know now that this is not the whole story.

Writing semantic HTML also means using native browser elements and controls in order to convey the meaning and purpose of the content. Understanding when and how to use HTML elements is not always easy, but correct implementation will result in a positive and successful user experience for people who depend on assistive technology.

There is information that needs to be present when an element receives keyboard focus in order for someone using a screen reader to navigate and consume that content. Focusable elements include links and form controls, and when the element is in focus, its text content and attributes are read out loud to screen reader users.

What is announced are a few important pieces of information:

  • The element’s accessible name or text equivalent
  • The element role
  • The current state of the element (if applicable)

What’s in a name?

The accessible name is the part that describes what the element is for, its purpose for being. This is usually found as the content between the start and end tags of an HTML element. It could also be the alternative text value for an image. For example, an anchor element (better known as a link) has text between its start and end tag. This text gets read aloud with a screen reader which gives context on what should happen or where the browser should go when that link is activated.

For example, a link in a navigation area with the accessible name of “Contact Us” would indicate that, if you activated that link, it would load a page with contact information, maybe a telephone number or address, and possibly a form where someone could send a message to the company.

A critical role

The element role tells us a few things, including what the element does and how to interact with it. Coming back to the link example, the role announced would be “link,” as links are structured with opening and closing a tags and a valid href attribute. The expected result or “what it does” would be the browser to either load a new page or jump to another section of the same page, shifting focus to a different page element.

Various element roles come with expectations on how to use them. Depending on the role, a user might expect they would need to press the Enter key to continue (as is the case with a link), use the Space key to activate a button, or use the up or down arrow keys to make a selection. A role can also signify a change of context, such as a modal window being presented on the screen.

What condition my condition is in

Alternatively, depending on the element at hand, there could be a state announced along with the element name and role information. Announcing the state helps to convey the current condition of the element, whether interaction is needed, and what might happen when the interaction takes place. For example, checkboxes and radio buttons have a “checked” or “unchecked,” and a “selected” or “unselected” state, respectively. An accordion style widget would have an “expanded” or “collapsed” state, indicating whether the content is on-screen and available for consumption (expanded), or if the content section will merely be skipped over when navigation continues (collapsed).

The semantics of an element are very important to keep in mind when writing HTML. This is how people using screen readers will know how to navigate and consume your site content and what to expect when interacting with an element.

Keep an accessibility mindset

When planning a course of action for marking up a new site design or a module in a style guide, consider the visual aspect and potential interactions for each element. Ask yourself a few questions, such as:

  • What is the design’s purpose or intention?
  • Which HTML element is best suited to meet the design requirements?
  • How will the element handle keyboard interaction, and how will a screen reader announce the name, role, and state of the element?
  • Is there a requirement to manage browser focus programmatically?
  • Is the text content clear, easy to read, and understandable?
  • Is there enough contrast to be able to read the text content?

If you feel any concerns when answering these questions, perhaps when reviewing an overly customized widget design that may call for non-native controls and interactions, consider having a discussion with the designer, project manager, or business owner to see if a compromise can be agreed upon in order to make elements and widgets more accessible for people with different needs. Sure, things may look pretty and modern, but if people can’t use it, what’s the point?

Always start with native browser elements before creating custom controls.

With native elements you are given semantics, built-in by default. Using these allows you to keep your site or app easier to maintain with less code, and it saves time by not reinventing the wheel. This also helps to guarantee things will work for less capable environments, older browsers or assistive technologies for example. If required, build upon these base elements with extra interactivity for browsers that support the latest features.

Putting it all together

Let’s look at this wireframe example for an FAQ section on a page.

A mock frequently asked questions section of a web site. The design includes a  show/hide style functionality. Three sections are presented, each with a show/hide link control alongside a plus or minus icon to represent its state. The control links are in order with a label of ‘Question 1’, ‘Question 2’, and ‘Question 3.’ The first content section is shown, revealing its answer text.

After reviewing this image, how would you decide on what the intended interaction would be for someone to consume this content? Which HTML elements should be used to convey the meaning and purpose? What will the elements sound like when focused, and how will someone interact with it by using just the keyboard?

From what we know so far, there is a list of text items along with “plus” and “minus” icons, giving an indication that this is an accordion style widget. When one of the list item controls is activated, the FAQ content will be revealed.

How should we write the HTML for each list item control in order to convey the meaning and purpose of the widget?

Which element should we use?

It’s fairly easy to make something work when using a mouse or touch input device. You could attach a JavaScript click event listener to a parent div or perhaps an h2 heading to reveal the related content and it would work just fine. The problem with adding click handlers to just any HTML element is that it won’t convey the correct meaning (semantics) for people who rely on assistive technology. When read aloud by the screen reader, the feedback needs to include information about the element, not only the name of the element but also its role (what it is) and its current state. This information gives insight on how to interact with the element.

People who only use a keyboard for input will also have a disadvantage, as divs and heading elements are natively unable to receive keyboard focus. So what should we use instead?

Correct semantics

The element we decide to use needs the correct semantic meaning in order to accurately convey the purpose of the widget, and by association, how to interact with it.

The element required for this interaction would need:

  • The ability to receive keyboard focus
  • A role which indicates that the element we’re focused on will shift focus upon activation (to the content container)
  • The browser focus to change, on activation, to the content container

Some developers may take this information and assume that they had to create a custom control with all these requirements. However, there’s already such an element readily available just for this task, the a with a valid href attribute. Link elements are, by default, focusable. Their role of “link” indicates that you can press the Enter key to submit its function, and that it will either open a new page or shift focus to somewhere else on the current page.

The first show/hide link of frequently asked questions section has a visual highlight around it, indicating that it has keyboard focus. There is a speech bubble above with the text, ‘Question 1, link’.
With this setup, our accordion widget list item control has almost everything we need to convey its meaning and purpose.

The state of things

One other piece of information we need to include for this accordion example is the current state of the list item control. An accordion control can either be “expanded” or “collapsed”. The state also helps to give extra meaning and context for what the element does and its intended purpose.

Since the accordion is a custom widget, we can accomplish adding a state in a couple of ways. We could either include some visually hidden text alongside the link text, or by applying an aria-expanded attribute, whose value would toggle to true or false on the click event.

Visually hidden text code example:

<a href="#answer-1">
    Question 1
    <span class="visuallyhidden">, expanded</span>

The same code example, using ARIA:

<a href="#answer-1" aria-expanded="true">
    Question 1

Whichever path you decide, be sure to test with a screen reader and make sure the state is announced as expected, and to update the state value on the click event in order for this content to be heard when the element receives focus. (Details on how to test follow in part 3 of this series).
The first show/hide link of frequently asked questions section has a visual highlight around it, indicating that it has keyboard focus. There is now a speech bubble above with the text, ‘Question 1, expanded, link’.

Managing focus

Oftentimes widgets or complex interactions require some extra attention with managing keyboard focus. This is the act of moving the browser cursor from one element to another in order to provide a seamless and understandable user experience for people who can’t see the screen and for those individuals who use the keyboard exclusively.

You know if a widget requires management of the browser cursor when an interaction takes place and you are required to move your eyes to begin reading the newly revealed content. In the same manner, the browser cursor should also be moved to the same location.

In the example of the accordion widget, on activation, focus will be moved away from the list item control and onto the container of the revealed content. From here, people will be able to continue reading the content from the next logical place. For screen reader users, the action of moving the browser cursor also helps to indicate that the click event successfully completed.

Now it’s your turn

The next time you’re presented with the challenge of writing a new piece of markup or fixing an existing bug, remember to use native, semantic HTML elements as a base. Consider how something might work when interacting with a screen reader or a keyboard. This helps people using your site understand the page layout, and it helps them to know where they are on the screen as they navigate around in order to interact with your content.

In the third and final installment of this article series, we will go deeper into what screen readers are, how they are used, and the basics of testing your code to see how it might sound with screen readers.

The post Listening to the web, part two: it’s all semantics appeared first on Simply Accessible.

]]> 2
Listening to the web, part one: thinking in accessibility Tue, 15 Nov 2016 18:42:57 +0000 Before we can boldly venture into the world of semantic HTML and screen readers, we must establish a solid foundation of thinking in accessibility. In this post, developer Scott Vinkle reminds us of the importance of creating and maintaining a mindset of inclusive thinking.

The post Listening to the web, part one: thinking in accessibility appeared first on Simply Accessible.


Article Series:

“We have some concerns around the way some of the form controls are designed. They’ll need to be completely customized in order to make them keyboard accessible and match the design. This means more time will be spent coding and making sure they’re usable. It also means a slightly longer loading time.”

“Yes, okay that’s fine. Just make it work.”

“We also wanted to bring up issues we found with the colour contrast of the primary text. The way things are now it will be difficult to read for some people who may have low vision…”

“Listen, we don’t care about accessibility. We just want the site to look as it was designed. Let’s move on.”

This was an actual, slightly paraphrased, conversation I overheard between my agency at the time and a design firm. I was floored.

We don’t care?

Why would you not care about making sure something was usable by people? Why design anything at all? Aren’t people the reason why we do what we do?

Before that project launched, we did all that we could. The site was mostly usable, but there were many issues that remained, not the least of which was that this approach didn’t demonstrate inclusive thinking.

I realized in this moment that no amount of technical know-how could convince people of the need to ensure an accessible user experience. Like most things, creating accessible websites is a process, one which begins with a mindset shift.


I wrote this post series as a way of introducing readers, and particularly developers, to the basics of working in accessibility. It’s a recollection of my personal experience over the last few years, learning and growing as developer with accessibility at the forefront of my mind.

We’ll start at the very beginning: thinking in accessibility. Developers often think about screen readers when they think about accessibility, so let’s explore that area. We’ll take a look at who uses screen readers, why and how. Then we’ll roll up our sleeves and get to work.

We’ll take a look at semantic HTML, aspects of elements and how to choose accessible elements which provide proper semantics. We’ll dive into how people use screen readers, commands every developer should know, and we’ll seal the deal with a look at issues and fixes on a demo site.

Most importantly, I hope after reading this that you’ll see how the technical skills are not the end but the means to serving a larger vision: one of awareness, inclusivity, and empathy.

Mindfulness is key

Consider this: When you’re driving a car, it’s crucial to pay attention to your surroundings. To be a successful driver, you must take into account other drivers, cyclists, road signs, and pedestrians. Without this consideration for others, you face the potential of getting into trouble quite quickly.

Along the same lines, as designers and developers, you help ensure a positive user experience for all when you are mindful of people and the various ways they use and interact with your website.

As you design, if you consider someone in a remote area of the world with a poor connection speed, you’ll make sure the site and all its assets will load quickly and perform optimally. If you consider someone doing research and learning about a topic using a handheld device, you’ll be sure to design a user interface that supports a wide range of device screen sizes and orientations. If you consider someone who is blind, hard of hearing, or who has difficulty understanding written text on a page, then you’ll code and structure content in a way that will help convey meaning and purpose for people who use and depend on assistive technology to experience the web.

What really happens is that as you start thinking of and developing for people with disabilities, you end up actually improving the usability of a site for everyone (for instance, people using outdated browsers or older handheld devices).

Being mindful of people’s abilities and showing empathy and compassion helps drive your development workflow and best practices in a way that is beneficial for everyone.

Who’s listening?

One afternoon while riding on a public bus, I noticed a gentleman across the aisle, holding his phone with both hands in a peculiar way. With his left hand, the phone was held up with the speaker end pressed tightly against his ear. His right hand was feverishly swiping and gesturing commands into the device, moving so quickly I couldn’t understand how he was able to make sense of it all. Shortly after, I realized that he was using the built-in screen reader software on his phone in order to find and listen to the content on the website or app. Witnessing this was a revelation to me. The experience showed me how some people consume content, and how important it is that front-end interfaces are well-equipped to handle various types of user interactions.

In a 2014 report, the National Health Interview Survey (NHIS) estimated that 22.5 million adult Americans either “have trouble” seeing, even when wearing glasses, or are unable to see at all. This is nearly 10% of the population, and a significant number of those people may rely on assistive devices and technologies, some using screen readers, to read and navigate the web.

People who use a screen reader can hear what’s on the screen by having a digital voice read aloud the content and interactive elements on the page. There are several kinds of people who rely on screen reader technology, including those who have low-vision or who are legally blind. Some people have difficulty reading text, while others need to have text read aloud as they do something else. Some people just want to listen to a lengthy blog post while cooking dinner! In other words, screen readers are not solely used by people with sight limitations.

When you consider that at least 10% of the population would benefit from screen reader technology, the time it takes to learn and work with a screen reader is not a waste at all. This knowledge will make you a great asset to any development team!

Bake accessibility in from the start

When I began my planning stage of how I’d mark up a new design with accessibility in mind, my whole outlook on development changed. I made sure to use native browser controls and logically ordered headings, colours that would pass contrast tests, and unobtrusive JavaScript which helped manage keyboard focus for complex interactions.

For the first few days on a new project, after studying the design files, making mental notes of what made sense to be repeatable modules, and talking with the designers, I would write HTML. Just simple, plain HTML without any bells or whistles. This provided me with a place where I could start testing with a screen reader for basic, low-level issues, things I could watch for and fix right away. I made sure everything had the correct semantics and context for what the elements were supposed to be.

With the HTML structure in place written as reusable modules of a greater design system, I would go in and start adding classes and writing the CSS in order to match the intended design. When the styles were added to a module, I’d again go in and test for accessibility issues. I would keep an eye out for any elements with a display property, taking note to ensure things that were visible (or not visible) would reflect this state when interacting with a screen reader. I’d also watch for element positioning. Things can get out of hand pretty quickly, so I needed to be certain that the visual order of content matched the order that would be found when using a screen reader. This way, everyone would get the same reading order for the content and avoid any possibility of confusion.

It may surprise some readers, as it did myself when I first started learning about accessibility development, that JavaScript plays a big part in writing accessible interfaces. This is especially true when creating dynamic widgets such as accordions or modal windows, or perhaps implementing a hidden navigation menu for small screen devices. By using JavaScript, we can dynamically create and inject extra elements and add the required attributes to further convey the meaning and purpose of our more complex user interfaces. JavaScript is also used to manage keyboard focus for any custom widgets or complex interactions.

We’ll dive a little more deeply into these concepts in the next part of the series but for now, the main point to take away is that we should keep people in mind and test for accessibility issues in each step of the development process. Let’s remember that what we do is for people, not for other designers or developers. In most cases, not even for ourselves.

Bake accessibility into each development iteration. Test early and often. Be mindful of your audience. By adding these small extra steps to your workflow, you’ll be making sure accessibility is ready and available right from the get-go.

The post Listening to the web, part one: thinking in accessibility appeared first on Simply Accessible.

It IS rocket science Thu, 10 Nov 2016 15:51:36 +0000 Whether it's traveling to Mars or staying competitive in our industry, we need velocity and maximum efficiency to get there. In this post, Charles Callistro shares his observations on how the concept behind the Photonic Railway applies effectively to the workplace.

The post It IS rocket science appeared first on Simply Accessible.

Recently, Elon Musk announced SpaceX’s proposal for colonizing Mars. My first thought was “Wow!” and my second thought was “that reminds me, I should finish that article I’ve been thinking about.”

You see, as I watched the animation of this incredible idea, the solar panels part actually disappointed me (check out a video of the solar panels here). The 200kw of power the solar panels draw is great for internal use; for lights, microwave ovens, all that human-related stuff that will need to happen. None of that will contribute to acceleration of the ship, however, and the ship will have an ‘interplanetary coast’ of 100,800k km/h. Most of these plans estimate about 6 months to get to Mars. This is too slow for me! We need to speed things up!

It’s not that I’m impatient when it comes to getting to Mars. I know all too well that in reality, we can’t coast in business.

We can’t find a velocity that’s stable and then rely on that velocity forever. Our competitors will find a higher velocity, the industry will change, technology will be developed, and today’s really fast will be next year’s quite slow.

What we have to do to stay competitive, and in fact, to be the example that I feel we are in our industry, is constantly accelerate. NASA feels this will be necessary technology as we begin to explore our solar and extrasolar neighborhood, and I feel this is necessary in the work world.

Some cool space stuff

NASA commissioned some research from a very smart guy named Young K. Bae on a method to speed things up, and I find it fascinating. Although it’s still in early experimental phases, it is theoretically and mathematically sound. Using this method, they’re guessing a trip to Mars could take a much more tolerable three to ten days. I like to think it will be an elegant trip, with a dining room and overstuffed chairs and that pets would be allowed.

This concept has lots of formulas I don’t understand, like this:

The mathematical formula for calculating the total photon thrust for Bae's propulsion concept.

But I do believe I understand the ideas that Dr. Bae is discussing. Usually when I’m trying to break down something complicated, I use my awesome MS-Paint skills because I’m preternaturally gifted in them.

Here’s how a basic rocket works:

An MS Paint illustration of Major Tom flying a rocket that uses traditional propellant.

You have the rocket part with the guys in it, but most of the rocket part is actually just a giant fuel (propellant) tank. The propellant burns and creates force, and when you turn it off (if you can), or it runs out of propellant, you coast.

What Dr. Bae did was work off a different model. What if you used a solar sail, which relies on photons to propel itself and anything attached to it, and aimed an Earth-orbiting laser at it? If you did that, your rocket wouldn’t need all that space for propellant which is upwards of 90% of the mass of the rocket. You’re pushing something while leaving the power at home. This laser system is called a Photonic Laser Thruster.

An MS Paint illustration of the solar sail model, which has a small compartment for people and a large solar sail driven by a laser. Image above not to scale

So now you have a vehicle with much less mass to push, and if you keep the laser pointed at it, it’s never coasting, it’s always increasing in velocity. This is great, like incredibly great. This is putting your foot to the gas pedal and there’s no floor beneath the pedal to stop it, it just keeps increasing.

Y.K. Bae realized how much better it can be.

One of the cool things about lasers is they are focused, their beams don’t expand as you point them, which is necessary to be able to really get some oomph for this versus a giant light bulb like the sun. Think about it.

What Dr. Bae figured out is so brilliant and simple. He realized that adding mirrors and bouncing the same light back allows it to be used again with no additional energy required.

An illustration of the same solar sail model, with the laser bouncing off of mirrors on the craft, increasing velocity.

Now we’re not only constantly accelerating, but we’re increasing the force applied by reusing the same light we’ve already generated!

Dr. Bae’s experiments are in early phases, but the most recent reports indicate that by using more mirrors we should be able to get one thousand times or more amplification through recycling the light.

Dr. Bae calls this a Photonic Railway, which is not only a cool name but a cool description. Think about it. The beam goes back and forth through mirrors to the ship a few dozen times. Then what? Then you bounce it off a different mirror and send it in a different direction, creating another path to sail on for another ship. You could even put mirrors on the ships and have them bounce light to each other, for example to one further ahead of it, and create a space ship train! Choo choo!

The same solar sail model with mirrors reflecting to other spacecraft. Hashtag mindblown.

Some Cool Work Stuff

Not only was I fascinated by the Photonic Railway, I also realized there’s a lesson to be learned here.

When working in a Lean environment, we strive to do more with less, and the Photonic Railway is a nice metaphor for that concept. By leveraging what we’ve created, we’re able to provide more for our clients.

I imagine some of you are thinking “you’re talking about recycling content!” and wagging your fingers, but I’m not suggesting recycling content. I’m suggesting the gathering of empirical evidence, through review of procedures, projects and interactions, in a way that allows us to utilize what works again, while also improving on it.

Rapid changes are always underway here at Simply Accessible, after all, our company meme is “Oh, that’s how we do it now.” Our metaphorical mirrors bounce information back and forth constantly. We recently delivered some data to a client in a way we hadn’t before, due to the client’s requirements. We were thrilled that the client liked the way we did it, and that got us to thinking, “Why don’t we do it this way all the time?” (This is a question I often ask after something goes especially well.)

A retrospective on this not only showed us that it was a good system, but also that it could be improved upon even further. Within two days, we were adding more features to the new delivery method and beta testing it with other clients, getting feedback and improving upon it constantly.

We weren’t recycling content, which is understandably a frowned-upon and shoddy business practice, but instead were taking something that worked particularly well for someone and expanding upon it to provide it to others, without reinventing the wheel in the process. Our clients are unique, and will always need and desire the attention to detail and craftsmanship we put in every project. This is about adding to that, not replacing that. Amplifying the light.

When something works well, bounce it back out to others. Improve on it. Add it to your toolbox, and make it your new standard – for today. By doing so, you’ll keep accelerating. Coasting is predictable, but also predictably slow. Rocket ahead!

The post It IS rocket science appeared first on Simply Accessible.

Turning a new page for print-disabled readers Tue, 04 Oct 2016 20:04:23 +0000 Access to knowledge is a fundamentally important right that many blind, low-vision, and otherwise print-disabled people cannot exercise due to limitations in federal copyright laws. The Marrakesh Treaty has been established to amend copyright laws to protect the copying of texts into accessible formats.

The post Turning a new page for print-disabled readers appeared first on Simply Accessible.

Each year, 95% of published works that are made available for the public cannot be enjoyed by people who are blind, have low-vision, or have reading challenges such as dyslexia.

Let that sink in a minute…95%.

As a way to combat what’s known as “the book famine” for the blind, September 30, 2016, marked the day that the conditions of the Marrakesh Treaty were put into effect for those 22 countries that agreed to its terms. These countries include Canada, Mexico, Australia, and India. While the United States, the European Union, and the United Kingdom have endorsed the Treaty, they haven’t yet accepted it into law. But it’s coming!

So what is the Marrakesh Treaty?

It’s a starting point: the beginning of the end to inaccessible cultural works including literature, sheet music, visual art, and dramatic performances. Access to knowledge, culture, and the arts is important for everyone, and considered a basic human right. Laws exist to make sure that this right is specifically inclusive to people with disabilities.

The Marrakesh Treaty to Facilitate Access to Published Works for Persons who are Blind, Visually Impaired, or Otherwise Print Disabled—to give it its long name—enforces countries to amend their copyright laws to no longer make it illegal to reproduce cultural works in accessible formats without consent of the copyright holder.


In other words, individuals who are blind, have low-vision, or have a print disability such as dyslexia, along with non-profit agencies who provide services to such people, can reproduce things like books and plays in accessible formats without the permission of the authors, playwrights or publishers (i.e. copyright holders). Thanks to the treaty, these copyright holders can’t take legal action against those reproducing their works for accessibility purposes.

So what does this mean for copyright holders?

The Marrakesh Treaty will hopefully encourage copyright holders to produce their own works in accessible formats if they want to keep the upper hand on the accessibility “pirates.” Arr!

In Canada, as in the other countries that have ratified the Treaty, if a copyright holder can prove that they have made their work accessible, and it is easily available to the public, and an organization has tried to copy a work for accessibility purposes, then the copyright holder can, in fact, still take legal action under the Canadian Copyright Act (PDF). Shiver me timbers!

Luckily, though, if an organization is selling accessible, copyrighted works, royalties must still be paid to the copyright holder.

Do copyright holders have to make their works accessible?

While the Treaty does not enforce publishers and other distributors of literary and artistic works to make accessible versions commercially available, litigation can still take place by people with print disabilities who cite The Convention on the Rights of Persons with Disabilities (CRPD). Much of the world, including Canada, Europe, the United Kingdom and Australia, has ratified the CRPD, so copyright holders in those countries may be held against Article 21 (Freedom of expression and opinion, and access to information) and Article 30 (Participation in cultural life, recreation, leisure and sport), to provide their works in accessible formats. If you are a copyright holder and do not have accessible versions of your work, it might be to your benefit to seek legal council.

While the United States has endorsed both the CRPD and the Marrakesh Treaty, both of these have not yet moved through into law. President Barack Obama has requested a quick ratification of the Treaty from the United States Senate, as provisions already exist in US copyright law that match those in the Treaty.

The Marrakesh Treaty is a huge step towards universal access to information, and we couldn’t be happier to have reached this monumental point in time. If you have a literary or artistic work that you’d like to make accessible, talk to us! We’d be glad to discuss your needs.

I know for myself, I wouldn’t mind having access to more audio books for long drives. How does this Treaty make you feel about the future of published works? Let us know in the comments below!

The post Turning a new page for print-disabled readers appeared first on Simply Accessible.

You already have a fan club Thu, 29 Sep 2016 18:00:54 +0000 We’re hiring! In true Agile form, Charles Callistro invites us to consider a less painful, more people-first, approach to the job interview. Prospective candidates, read up!

The post You already have a fan club appeared first on Simply Accessible.

We’ve been hiring lately (after reading this go to our jobs page!) and I’ve found the interviewing process to be very exciting and enlightening, which has been a pleasant surprise.

We’re committed to our culture at Simply Accessible, in which our shared values of respect, transparency, and inclusion are mirrored throughout the activities we perform, and hiring is included in that approach.

The first thing I realized while attending these hiring sessions is that it’s much more fun to be the interviewer than the interviewee. That should be obvious, but I’m stating it because the observation presents an opportunity while raising a couple of questions: Why is it so painful to be interviewed for a job, and how can we make it less painful?

So many questions

So far, the things I’ve identified as worrisome about being interviewed are:

  1. What will they ask me about?
  2. What are the right answers?
  3. How am I doing so far in this?
  4. What else do I need to know?

So, in the interest of helping people out, let’s try to address these up front.

What will they ask me about?

We’re going to ask you to tell us a bit about yourself and your recent work. We’ll be glancing at your LinkedIn profile as we do so, but a lot of this will depend on the kind of job you’re applying for. If you want to be a tester for us, we’re looking for an analytical mind, but also to determine what your motivation is. You obviously like to solve problems, but WHY do you like to solve problems?  We’re also quite likely going to ask you how you found us, and what interests you about working with us. Questions like these really help us to get a feeling for why you’re here.

What are the right answers?

In a very general sense, we’re looking for people who are both very good at their professions and very excited by the prospect of adventure. We have an internal meme, “This is how we do things now.” This was stated by a co-worker after a week-long vacation. We pivot often and improve in a flash, and this goes for our roles as well.

We’re looking for people who want to constantly refine and improve their positions, not maintain them. Doing something well 10,000 times the same way is actually doing it pretty poorly. Doing it well three times and finding a better way to do it is what we want. Come to us with a dream of how things should be done, and you’ll find a very receptive audience!

How am I doing so far in this?

You could ask. One thing I’ve noticed, and don’t like, about most job interviews is an implied formality that isn’t realistic or helpful. If you’re working with us, we’re going to be talking with you every day about a variety of things. Your “best behavior” isn’t how you really are, and we need to know how you really are! And, if you’re really looking to improve (as mentioned earlier), then start with the interview itself.

What else do I need to know?

At the end of interviews I’ll sometimes think, “If I were that person and wasn’t feeling pressure, I’d ask <this stuff>….” and sometimes I actually do ask for you. Most frequently, these things include:

Why are we talking to you?

Something in your background or introduction letter excited us. Simple as that. Find out what that was.

What are the next steps?

We’ll tell you, and some of it depends on the anticipated role. We’ll definitely have an internal discussion, and if we feel this is a good fit, we’ll move forward. If we unfortunately don’t see this as a good fit right now, we’ll let you know that too; nobody should be left worrying.

What about salary? Vacation time? Benefits?

Those are beyond the scope of our initial talk. You should want those details to make sure you’re making good use of your time on this, but at this point we’re still trying to get a feel for you. Those details will be worked out soon.

I thought of the perfect thing to add, five minutes after the interview ended! What should I do?

What would you do if you forgot to ask or tell anybody anything? Ask! Tell them! Send us an email with an awesome addition.

The last thing I’d like to add is this: relax. Don’t consider us a room full of strangers–consider us a room full of your fans, because we are. Your job is simply to explain to us how right we were about you!

Ready to meet your fan club? Check out who we’re looking for.

The post You already have a fan club appeared first on Simply Accessible.

Finding the willing: cultivating engagement for accessibility Thu, 01 Sep 2016 23:54:36 +0000 Keep your garden of accessibility in bloom by engaging a network of people who share certain values and span all parts of the organization.

The post Finding the willing: cultivating engagement for accessibility appeared first on Simply Accessible.

Previously we’ve written about how accessibility is the responsibility of everyone in your team, and how agile and accessibility thinking go hand in hand. As your organization embraces accessibility and begins to transform practices and priorities, one of the most difficult hurdles to overcome is identifying people to lead accessibility efforts in day-to-day work. After the initial push has ended and the adrenaline has worn off, who will keep the momentum going? We’ve found that it takes a network of people in all parts of the organization who share certain values to keep the garden of accessibility in bloom.

Tilling the soil

a trowel full of soil

When we work with clients to build sustainable accessibility programs, we collaborate with them to identify how leaders and managers can support accessibility for the long term. Beyond prioritizing accessibility at the organizational level through policy and practice, leaders can encourage accessibility engagement in a few additional ways.

  • Create a diverse team. There’s been a lot of research around how diverse teams create better workplaces and products, and accessibility work is no exception. Hiring employees with diverse backgrounds, abilities, and experiences creates a team of individuals who solve problems creatively (and differently than each other) with more flexibility than homogenous teams.
  • Reward self-management. Team members who feel like they have freedom to learn and integrate that learning into their work can bring knowledge and information into an organization that wouldn’t otherwise be there. By allowing people to explore topics that interest them, you encourage them to become subject matter experts and allow them to feel in control of their own professional development. Similarly, when people have some say in how they manage their time, it helps them work in a way that best fits their work style within the goals of the team.
  • Fill the toolbox. In addition to the time and education needed for teams to succeed with accessibility, this work requires resources, whether those resources are software, keyboards, office chairs, or snacks in the kitchen. For teams to do accessibility work effectively, they need to have access to the tools they’ve decided to use to do that work. Make sure that procurement, distribution, and maintenance of those tools goes smoothly, it’s an important part of helping team members feel like the work they do is valuable.
  • Leave space for failure. One of the biggest challenges with accessibility is accepting the learning curve.

Team members in every role must learn (and unlearn) certain expectations, practices, and skills to do accessibility work, and it can be frustrating when initial efforts feel stressful and unsuccessful.

Creating products and services is a process, and, just like gardening, there will always be mistakes. It’s important for organizations to identify those mistakes, evaluate and learn from them, and determine how to avoid them in the future.

How your garden grows

seedlings in a tray

So now that your organization is creating a fertile bed for accessibility efforts to flourish, how do you find your gardeners? Your team probably won’t be chock full of accessibility experts right away. In addition to an interest in accessibility, there are some things you can look for that demonstrate the types of qualities that make a great accessibility thinker and doer.

  • Adapts easily to new tasks, tools, and processes. Accessibility requires rethinking how we do work, and that comes with learning new tools and techniques. People who can adjust readily to integrate new information into their day-to-day work are generally more open to the types of workflow changes that come with engaging with accessibility.
  • Empathizes with users. The end goal of accessibility is to make content for all users. Understanding user goals and empathizing with their needs is a requirement for making a truly accessible experience.
  • Volunteers to talk. Team members who speak up in informal and formal settings typically have strong feelings about the work they and their colleagues do. Since accessibility requires internal and external advocacy, seeking out people that already have empathy and passion in their teams can help.
  • Pushes for standardization. Members who push for standardization and documentation in the form of code standards, pattern libraries, annotated mockups, and the like within their team are quick to see the benefit that these types of artifacts provide for maintaining accessibility.
  • Shares information. In addition to standardizing documentation and communication, team members who openly share and collaborate with their coworkers make great allies. People who seek collaboration over competition see the benefits of laying everything out between members of the team so work can be easily handed off with fewer questions and hurdles.
  • Invests in the company culture and mission. Team members who are invested in what the organization is trying to do will also be invested in doing the best by your users and customers. People who take pride in the work they do for the benefit of users and supporting the organization’s goals are willing to stick through the hard times of organizational change. They don’t just celebrate the victories.

In full bloom

sunflowers in the sun

As efforts take root, it’s important to create ways for your accessibility gardeners to interact and support each other, as well as to find new members of the network. Just like you wouldn’t expect a single person to conceptualize, design, develop, test, and release an enterprise-level product or service, a single person cannot be responsible for accessibility in your organization. It requires a network of people, in different roles and on different teams, to share in the intellectual and emotional labor that comes with accessibility work. A network combines the work of  design, development, testing, product and leadership teams to create consistency across the organization.

  • Documentation, discussion, and sharing within teams. Members of a network collaborate on and share results of accessibility improvements within their teams. Since improving accessibility means improving design, development and test practices, team members who aren’t prioritizing it may feel left behind as a critical mass forms around accessibility. Teams can use peer review, brainstorming sessions, sprint planning, or any other forums for discussion to make sure everyone is on the same page.
  • Mentoring. Integrating discussions about accessibility into mentoring helps reinforce to junior team members that it’s a priority, and helps senior members see how those junior members are adjusting to the changes accessibility work has made to their professional development.
  • Cross-team groups. Informal and formal meetings across the network can go a long way to create a sense of community for people doing accessibility work in an organization. They’re especially important when members of that community are spread across the organization. If you don’t work or communicate daily with other members of the network, it can be easy to lose sight of the connection. Informal meetings to share ideas and time to work on cross-team projects allow those networks to blossom. The most important things these meetings and project groups can accomplish are creating consensus on practices, tools, and processes across the organization, taking into account the needs of team members in all roles. These same groups can present and demo improvements across the organization, tools, and outcomes to colleagues and leadership.
  • Volunteering for organization activities and efforts that help the community. Since accessibility is part of making the world a better place, it goes hand in hand with any efforts the organization makes for the larger community. The presence of members of the network at company-wide fundraisers, volunteer efforts, or other events helps cement the place of accessibility as a positive effort for team members’ colleagues. Team members who express an interest in accessibility may already be involved in these activities and will be eager to evangelize.

The specific ways you engage members of your organization in accessibility will be as unique and varied as the members of your team and your company culture, just like every garden is different depending on its climate, soil, crops, and the people who tend it. Odds are, you can find members of your organization that will go the extra mile to help move your accessibility efforts forward. And, you can use your existing methods for building teamwork and camaraderie to find and nurture a network of future accessibility experts. It just takes time, patience, and a willingness to get your hands dirty.

The post Finding the willing: cultivating engagement for accessibility appeared first on Simply Accessible.

Extending the lifeline: meet James Edwards Thu, 18 Aug 2016 23:45:46 +0000 Representing the Simply Accessible team from the West Midlands, web developer James Edwards brings a multidisciplinary approach to accessibility. (He also likes to sing.)

The post Extending the lifeline: meet James Edwards appeared first on Simply Accessible.

James Edwards

Reaching a wider audience

Composer, singer, tap-dancer and Stevie Wonder fan, James Edwards brings a unique sensibility to the Simply Accessible team.

Trained in contemporary music, James originally turned to website creation as a way of floating his music across the Internet in search of an audience.

He soon found his web development skills to be in demand, and it wasn’t long before he became a webmaster and JavaScript programmer. When he began to learn about XML, particularly the names of elements and how they relate to semantics, he saw there was a bigger scope to the web development scene. At the time, James believed that HTML was primarily a visual language, and once he came to understand that the elements were actually all about the semantics, not the appearance, and that assistive technologies rely on semantics to understand what content is, it made him think: Who benefits from all of this information?

It was an audience he hadn’t even known existed.

James had never considered the impact of web development in this way and, as he puts it, the discovery blew his mind. It also sent him down the rabbit hole of web accessibility, eager to learn how these interfaces are used, and by whom.

James quickly caught onto the need for an accessible digital world. Acutely aware that technology is a lifeline for people, whether they are isolated by physical disability or geography, James knew that a more inclusive approach to web development was just the right thing to do.

It was just a matter of time before he met Simply Accessible’s Derek Featherstone at a conference, and magic happened.

Enhancing the audience experience

Although James no longer makes music professionally, there’s no denying the influence of music on his thinking. To James, the relationship between web developer and user is not unlike the dynamic between composer and audience.

“When people hear music they don’t experience the music the same way as the musician does. The musician hears the parts and the structure but all the audience hears is how it sounds.

The same goes for the user of your site. For the most part, they have no idea how it fits together, and they don’t need to. What they care about is how they can use it, their experience of it.”

James knows that as a musician, particularly a composer, it’s easy sometimes to forget about your audience, to think that what you’re doing is just for yourself. But it isn’t. The audience is integral to the music-making experience. The same is true for web development, so why not approach it in a way that will reach the widest audience?

The artistry of accessibility

James contributes as web developer and assessment consultant to the Simply Accessible team. He sees the benefits to both, and enjoys the interplay between the roles. He brings his developer mind to assessment work, and his assessment mind to developer work.

Where the developer work can become insular at times, James always emphasizes bringing a yin/yang approach to the task at hand. This allows him to navigate between the details and the big picture with ease.

It’s exactly this aspect of James’ work that allows him to have the pleasure of craft and composition, knowing that he is playing a part in creating an excellent web experience for the widest audience possible.

The post Extending the lifeline: meet James Edwards appeared first on Simply Accessible.

Julie Grundy wants to unlock the internet for everyone Thu, 04 Aug 2016 14:00:51 +0000 Here at Simply Accessible, while most of the Western Hemisphere team is asleep, the accessibility boat keeps cruising forward thanks to our cheerful Australian Accessibility Consultant, Julie Grundy.

The post Julie Grundy wants to unlock the internet for everyone appeared first on Simply Accessible.

Julie GrundyMore internet for everyone

Why does Julie Grundy do what she does?

Because she loves making the digital world better. We chatted via Google hangout, with a surprisingly good connection that had me feeling like Julie was in the next room, certainly not 11,273 miles away. “At the end of a project, when we compare where we started with where we ended up, so many more people can use this because of what we’ve done. It’s rewarding.”

Julie’s approach to accessibility is simple: Why not make the internet better for everyone? The way she sees it, the internet is a great source of information that has also democratized publishing. This means anyone can contribute anything. The idea of accessibility means more people with disabilities, people who are usually excluded from this kind of participation, can contribute on their own terms. Julie loves that her work is her way of issuing the invitation: “Come on in! More internet for everyone!”

There’s accessible—and there’s accessible

Before joining the Simply Accessible team, Julie worked as a front-end developer in the e-learning industry. When a national client asked for a project to be made accessible, Julie didn’t even know what that meant.

Undaunted, she jumped into the task with curiosity and willingness.

It wasn’t long before Julie’s sharp attention to detail revealed to her the difference between technically accessible and truly accessible. She saw the large gap that existed between meeting a checklist of solutions that were “technically” correct, and actually making a site that was usable, and even fun, for everyone. It goes without saying she delivered an exemplary end product for that client. So much so, in fact, that she soon attracted the attention of Perth’s accessibility community. For Julie, the opportunity also solidified her belief in the power of accessibility.

Knowledge is power, and the internet makes it all available. You can’t just lock people out of it. —Julie Grundy

Eagle-eyed and empathetic

After her accessibility awakening, Julie soon found that not only did she love helping make things better, she also loved the people she was surrounded by. People who wanted to create a better experience for everyone, not because it would make them rich or famous, but because it’s the right thing to do. These people, Julie among them, truly make up the front lines of the accessibility movement.

Julie works well beyond the traditional view of assessment being the place where “bugs” are “fixed.” Indeed, she is a living, breathing reminder of just how valuable the unsung heroes of the accessibility world are. Assessment consultants, testers, people doing quality assurance, all of them have their eye on the same prize: to make sites and apps better for everyone. Day in and day out, Julie and her global peers are all-in, finding opportunities for client teams to improve their accessibility practices and start creating accessible sites from the ground up.

Julie brings eagle eyes and a passion for detail to her role as Accessibility Consultant at SA. She works hard for our clients, tracking down accessibility issues and guiding them towards the best practices that make their sites usable for everybody. She’s known for her ability to work independently and she will admit it, she enjoys the detail work and the rabbit holes it takes her down.

Although when Julie is off work you’re likely to find her at the dog park with her two whippets, Rory and Biscuit, she is a true people-first thinker, and a cheerful delight on the Simply Accessible team. People like Julie are making the digital world brighter, better, and a lot more fun for everyone!

The post Julie Grundy wants to unlock the internet for everyone appeared first on Simply Accessible.

Agile accessibility: on razors Thu, 21 Jul 2016 17:04:08 +0000 Simply Accessible’s Agile Coach shares his thoughts about Occam’s and Hanlon’s razors—and how these two discovery tools can help in life, agile practice, and accessibility.

The post Agile accessibility: on razors appeared first on Simply Accessible.

One (just one!) of the great things about my job as Agile Coach is I get to ponder. I like to think of myself as a fairly good ponderer, so I enjoy this work immensely. I’ll see a complex process problem at work and ponder how we can best solve it. Thankfully, in the 21st century, I can access what others have noted about the same ideas and learn from them. Other times, I’ll find something interesting and seemingly unrelated, and then realize we can apply this to our work.

My thoughts on razors are in the second camp.

Occam’s razor is pretty well known, and it’s easy to explain if you aren’t familiar with it. (The Occam part is because it was proposed by a guy named William of Ockham about 700 years ago.) A razor is, in scientific or philosophical terms, a discovery tool—a rule of thumb that can eliminate, or shave off, unlikely explanations.

Occam’s razor can be summed up as: the simplest answer is usually the correct one.

For example, if I hear tires squeal outside, followed by a loud thump, it’s probably not a time-warping Napoleonic army fighting a dinosaur on my front lawn. The noises I’m hearing are much more likely a result of a car accident, and I should respond according to that assumption.

Cutting to the chase

As humans, we seek patterns in our life and work, which is often a very valuable thing. But, we also tend to find patterns when they aren’t there. This is called apophenia, and it can cause problems.

When we rely too much on patterns, we lose sight of the glaring, simple, and obvious answers to things. Occam’s razor reminds us that any problem has a likely cause, and addressing that likely cause will usually remedy the problem.

Hanlon’s razor, lesser known but related, is what I’ve been thinking about most lately. (Again, the Hanlon part is about a guy named Hanlon.)

What Hanlon’s razor states is: we shouldn’t assume malice over neglect, carelessness, or misunderstanding.

Some people add stupidity to that list, but I don’t care for that; it seems negative and not helpful.

When things aren’t going well for us, it’s very easy to assume malice. If we’re frustrated about a problem at work or home, it’s a short leap to convince ourselves that somebody is ruining our efforts on purpose. “My car isn’t fixed yet. Therefore, the mechanic must hate me.”

Almost always, this isn’t the case.

Most likely, the mechanic is waiting on a part, or the fix for your car involves several steps that take time in between, or there’s some other perfectly reasonable explanation. And perhaps due to neglect, or being busy, they forgot to mention this to you. They might have even forgotten that they forgot to mention it!

By removing malice from the thought process, we understand the situation more clearly—which liberates us to make decisions and take actions that remedy the problem.

There’s nothing we can do about a mechanic who actually hates us in the immediate timeframe. There is a lot we can do if we assume they neglected to tell us or we didn’t understand a pertinent detail.

Our frustration turns into a workable action plan: We can call the mechanic and re-establish a timeline. We can ask questions about more details. We can even offer to help. “Is there anything I could do to help the car get fixed?” Often, a willingness to help will show an interest in moving something along, and that alone shifts the momentum.

To translate this into agile terms: you create a shared commitment and establish a positive desire to achieve completion that others take into consideration in their prioritization of activities.

Razor-sharp accessibility for teams

Using these principles may help you get your car fixed faster, but it’ll also help you in everything related to accessibility. For example, the largest accessibility problems we encounter relate directly to complex, over-engineered solutions that haven’t considered the simple approaches to design and development problems that benefit everyone.

When you’re designing widgets or developing web forms, Occam’s razor still holds: the simplest solution is often the best (and most accessible).

Hanlon’s razor holds, too.

On any given day, I work with a dozen different people in different roles who all have their own mandate for success in their jobs. When an organization begins a journey in accessibility, people across teams have to embrace radical changes in the way they work. That can cause a lot of anxiety and friction.

As accessibility advocates, it’s tempting to assume that others are not only apathetic to inclusive design, but perhaps actively looking to block your efforts. However, considering that this may be the first time people have been introduced to accessibility in their work, it’s more productive to assume that a developer isn’t purposefully trying to ruin your web form and block access for people with disabilities. It’s much more likely that she just isn’t aware of the impact of inaccessible code.

On the flip side, a client-side development team might assume an accessibility specialist is making things harder on them than is necessary. That asking them to question the underlying assumptions of their user experience is a cruel waste of time and we should just get about fixing issues. But chances are, that specialist is actually trying to save developers’ time. Thinking about all kinds of users in the design phase removes the need for complex workarounds (which may cause more problems in the long run), repeated remediation, or shoring up inaccessible legacy code.

If you keep Hanlon’s razor top of mind, tensions decrease, and you can quickly form a plan for accessibility awareness and action.

I encourage you to ponder these principles in work and in life—both razors can help avoid unneeded complexity and conflict. Occam’s can help you design and develop simple, accessible users experiences. And Hanlon’s can help you collaborate more smoothly with teams.

Since we tend to repeat what works, you’ll find the more often you assume the likely, and remove malicious intent as a root cause, the load becomes lighter in general. Another bonus is you begin to see relationships in a more positive light, which can make every day better.

And, if you didn’t like this blog post, it’s obviously because you hate me.

The post Agile accessibility: on razors appeared first on Simply Accessible.

Ecommerce and accessibility: Do the Woo podcast interview with Devon Persing Thu, 14 Jul 2016 15:27:06 +0000 Devon was a guest this week on Bob Dunn's Do the Woo podcast for WooCommerce online store owners. Devon brought her down-to-earth and holistic perspective about integrating accessibility into ecommerce sites, and both the challenges and opportunities that await folks building purchase path experiences for their users.

The post Ecommerce and accessibility: Do the Woo podcast interview with Devon Persing appeared first on Simply Accessible.

I had the pleasure of speaking with designer, blogger, and content enthusiast Bob Dunn for the latest episode of his podcast, Do the Woo, covering ecommerce and WordPress. We chatted about the challenges and benefits of providing accessible shopping experiences for online customers—and the ways ecommerce sites can start to make their platforms accessible. Bob and I hashed out some ideas about emerging technologies and the internet of things, both great opportunities for reaching customers with a whole variety of disabilities.

Listen to the episode on Bob’s site, or check out the transcript below.

What kind of experiences have you had with accessibility and online shopping? What do you think ecommerce sites need to think about for customers with varied needs? Tell us in the comments!

Podcast summary

Podcast transcript

This is the transcript of a podcast recorded on July 6, 2016, between Bob Dunn of BobWP and Devon Persing of Simply Accessible. It was recorded over Skype and published as part of Bob’s Do the Woo podcast on July 13, 2016.


Bob: Hey everyone, welcome to episode 21 of Do the Woo, a podcast for WooCommerce shop owners. Bob Dunn here, also known as BobWP on the web. Today we’re talking about a hot topic which just about every website on the internet needs to actually be a part of, and that is accessibility. In today’s show we’re digging a bit deeper into it, exploring how accessibility and your ecommerce site play such an important role now and in the future. To help us better understand this, we’re talking with Devon Persing from Welcome to the show, Devon.

Devon: Thank you very much.

Bob: Over on I see that their tagline is, “We believe in a digital world for everyone.” Devon, why don’t you tell us more about yourself, the site, and what Simple Accessible is.

Devon: Sure. Pretty much what I do day to day is—and what we do as a company is—work with clients to make their websites more accessible, which very broadly just means making websites, and mobile apps as well, that everyone can use. That includes people with disabilities. It’s really a people-first way of thinking about improving technology and trying to make technology as precise and software agnostic as possible. Really, it’s about making things that are technically usable as well as pleasant to use for everyone.

Bob: Okay, that’s good in a nutshell. I think it’s such a hot topic right now. I know in the WordPress world there’s a lot of real advocates of accessibility and they’re trying to get it across the plate more to everyone and get more people aware of it. I think it’s kind of a challenging subject, too, because I know that some people think they know what it means—and what you just explained in a nutshell, that’s what it is. But, since they think they know what it means for a website to be accessible, can you give me or give our audience a more broad definition of what it means for a website to be accessible?

Devon: Sure. Typically people look at the W3C standard, the web content accessibility guidelines, which is really meant as a framework for being able to make things accessible. Their rules, from the same people who brought you all of the specifications for how you’re supposed to write HTML and JavaScript and those sorts of things, those guidelines are really about creating the scaffolding to create an accessible experience. It has things to do with making sure that there’s keyboard support for people with dexterity issues, making sure that someone uses a screenreader can access your website. They’re technical guidelines or recommendations that are meant to give you the tools you need to be able to make an accessible experience.

The harder part is then taking those technical guidelines and making sure that the thing that you built is still actually usable and pleasant for people to experience. I think one of the challenges we see is that people look at those guidelines as sort of a checklist and they’re like, “Well, it does all these things, so it must be accessible.” It’s very possible to build something that is technically accessible but still hard to use. A big piece of it is really usability and making sure that the thing that you’ve built that’s technically correct is still actually usable by people. A big part of what we do, in addition to assessments for clients is we’ll look at their websites and their apps to see if they’re, how technically accessible they are. We also do usability testing with users who have disabilities. We have actual humans looking at your websites and seeing if they can actually complete a transaction or do any sort of other experience. It’s really the technical piece and the sort of design piece, and then also the usability piece all together.

Bob: Yeah, okay, that makes a lot of sense.

Strengths and weaknesses

Bob: Looking at where we are now, I know this has been—I can’t even really say how long I’ve heard about it and heard about people getting into it more and more. What would you consider to be the biggest stride that has been made with getting websites accessible as of now, and on the other end, what is the biggest weakness you see right now?

Devon: I think for strengths, there’s a couple of things. I think one has been mobile thinking and mobile design has really made people start to think more about streamlining the user experience and streamlining the interaction those people need to go through to complete whatever they’re trying to do. Mobile has been huge in terms of just helping people think about making an experience that works end to end. The screen is smaller, you have to do things in a certain order usually, and you really have to think about what is the best workflow for a user. Sometimes, if you’re on a desktop experience, you can sort of put stuff anywhere and it gets harder to think about things in that sort of more streamlined way. That’s been huge for, just in general, creating experiences that are easier for people to understand and easier for people to get through.

I think the other thing we’ve been seeing a lot this year is that organizations are coming to terms with the idea that accessibility isn’t sort of a one-off technical fix they need to do, maybe to meet certain guidelines or to meet a legal deadline. It’s really something they need to take into their organization and make a part of everything they do the whole time from when they’re designing a product and thinking about what an experience might be like to building it and designing it into testing it and making sure it’s actually usable. It’s not one person’s job, it’s really the responsibility of everyone in the organization. That’s something we’ve been seeing people are coming around to in realizing: that they need to think about it that way for it to be successful.

As far as weaknesses go, I think, sort of in a similar vein, mentioning about looking at the criteria as sort of a checklist. Organizations are going to have situations where they’re maybe being sued or there’s a threat of suit. It’s easy to think about accessibility as something that’s scary and hard, and also maybe antithetical to what they’re trying to do. People can start to think about accessibility issues as a bug list they need to fix, which again, sort of goes against the idea of this being part of an overall experience. I think that’s still a challenge that we see a lot. Not being scared by it, I think, is a thing. As it’s becoming a bigger thing and you see more situations where organizations are having to think about it, either because of legal pressure or laws or whatever is happening. It can be a challenge to help them think about this as ultimately a good thing for their organization. It just feels scary when the first thing you are approached with about accessibility is something bad is going to happen to you if you don’t make your website accessible.

Bob: Yeah, yeah. That’s interesting.

Themes, plugins, and accessibility

Bob: One question that kind of came to my mind, and I don’t even know if you have any thoughts on this or if you’re the right person ask, but when you were talking about mobile, from the accessible standpoint, do you see one being better over the other? In the WordPress world, we have all these themes that work for mobile automatically, and then there’s these plugins and other things that can help your site to become a mobile site by maybe creating a mobile-specific site. Between the responsive design and plugins or apps or whatever that help you do that, is there one that you think is really going in a better direction for accessibility than the other? Or does it really depend on each one and how they work?

Devon: I think it depends on what the plugin or theme is actually doing. In general though, only having to worry about one version of your site is easier just for maintenance and also it’s just less of a headache. We’ve seen a lot of success for clients who have mobile-first design that just works across devices. One of the other things we’ve seen a lot, as organizations are moving towards actually responsive mobile-first frameworks or themes or whatever it is they’re using for their sites—it’s a huge benefit to low-vision users on desktop because they might be resizing the content in the browser. They’re not seeing a desktop website with the text bigger, they’re actually seeing the tablet layout or the mobile layout, which can be much easier for someone to use if they have vision issues. That’s just an extra benefit that you get from doing it with a single theme. I think from the perspective of having been a developer and knowing the pain to maintain multiple things that you don’t have to, as well as just seeing users interact with those, I think having a single solution is usually easier for a bunch of different reasons.

Bob: Yeah, that’s good to hear because that’s obviously the direction WordPress and the themes are going in. I know that’s what I’ve used myself. Good news to hear that that’s one of the better routes to go. Stepping away from the broad accessibility that we’ve been talking about, I kind of want to focus a little bit on ecommerce. When we were chatting before we started the podcast, I was telling you how it’s been a challenge myself to find somebody that is in that accessibility field, but who also understands the unique challenges that come with ecommerce sites and accessibility. I know, basically, people need to shop, and they need to shop online and be able to do that easily.

Challenges for ecommerce

Bob: What are the unique challenges, whether they’re technical, usability, whatever, that ecommerce store owners have as far as making their site accessible? What are you seeing as a constant challenge with online stores?

Devon: I think the biggest thing is that you’re usually trying to present so much information to a customer. You’ve got recommendations, you’ve got photos, you’ve got videos, you’ve got text descriptions, you’ve got controls to configure a product or pick a size or colour. There’s just a lot of stuff going on all the time. Start going back to what I was talking about a little bit earlier about trying to streamline and figure out what is the best way to present all this information to a user that isn’t overwhelming. Something that’s going to work on a smaller device, as well as something that the order of the content is presented in a way that’s logical. That’s difficult, especially when you bring in dynamic content. You usually have some search results you might be able to filter and do different things the user can interact with, and they can customize their experience. You also have a lot of forms that people usually need to fill out for shipping information and their personal information.

It’s basically this perfect storm of all the things that are usually really difficult for organizations that are first starting out. And that’s not even getting into making sure that your photos have descriptions that convey the same information to users who can’t see pictures of the product, things like that. There’s content challenges around what is the way to convey any non-visual information or descriptions or anything that’s included. Coming up with a user experience and a layout that supports different ways that people are going to interact with the site. Making it so that users know if content is updating dynamically—someone changes a setting and the price updates—you want to make sure that that is presented in a way that they can understand what’s happened. Making it so they can fill out forms with as little stress as possible. Forms are one of the things that are everywhere, and there’s some really specific technical things to do to just make sure your forms are accessible. But, there’s still a challenge because, like you’re saying, often people are building ecommerce sites with plugins. They’re using a bunch of third-party JavaScript libraries. You’re trying to get all of these different things that sometimes you don’t have control over to work together, and there’s just a bunch of stuff.

Bob: Yeah, I was just thinking it seems overwhelming. I was thinking of those forms, I thought, “Man, those…” Some people have challenges with forms that don’t have disabilities.

Devon: Absolutely, absolutely.

Bob: Wow. On that same question, has there been any research done or that you know of about how many people with disabilities  feel it’s a good thing, or it’s easy for them to shop online?

Devon: I’m not aware of any. I do know that, in general, the purchasing patterns and preferences and things like that of people with disabilities typically are just the same as everyone else. In general, people want to be able to shop online, they want to be able to shop from large online retailers that have lots of different options for them, they want to be able to use mobile apps and buy stuff on their phones, because you never know where you might be. You think of something, you want to buy it, you don’t have to wait to go home to your desktop computer, which a lot of people don’t need to do most things day to day. Pretty much all the same things that everyone else does people with disabilities want to do as well with technology in general and for online shopping in particular.

Bob: Yeah, that totally makes sense, and that’s what I was thinking. I was just kind of curious if there was any other insight to that.

Best practices for accessible ecommerce

Bob: Obviously you and your team are working with tons of sites and seeing all sorts of things out there and major screw-ups and probably sites that are perfect. But have you found any really interesting or creative ways that any online shops are addressing the needs of accessibility, something that you’ve thought, “Wow, this is kind of cool”?

Devon: I think a lot about it. I keep coming back to this idea of sort of streamlining and making things as easy for a person to get to the process. I think there’s already such a small margin. A person shows up at a website, they look up a product, maybe they put it in their shopping cart, maybe they leave it in their shopping cart for two days. And then, the actual conversion percentages for people actually buying stuff is already low enough that a lot of the things that companies are already doing to try to shorten that are also good for accessibility. Things like being able to save your credit card information, your details, anything that reduces the amount of forms you have to fill out. That’s super important.

I think in general, not trying to create a separate experience. There are still online shopping sites, I won’t name them specifically, but there are still places that, depending on the technology you’re using to access them, you might be encouraged to go to a separate website, which is never as up to date, never provides the same experience. I think there was this initial idea that we’re going to have a website and then we’re going to have something that turns our website into a website that works better on a phone. There was that initial idea, I think, about, “We just need to create a separate thing because doing this is going to be hard otherwise,” but the overhead for maintaining a separate website or separate experience is going to be so much more than just doing it right the first time. I think it’s just created a better, more streamlined experience in general for people to have something you can use on a phone, you can use with a screen reader, you can use it.

One of the things that comes up a lot for shopping sites is contrast, the colour contrast for controls. One of the things that’s really great for low-vision users, which is having sufficient contrast on any sort of device, means that you can look at a website if you’re in really bright light on your phone and still be able to read it and still be able to do what you need to do. There’s a lot of overlap and benefits for just shopping in general, when you think about things in the way it’s going to make sense for users that are consuming that content and a variety of different ways.

Bob: Yeah, I know that I was listening to a presentation, it was at a Woo Conference, and they were talking about colours, contrast, and they were talking just about how important. I’m sure you go on sites and you see this horrible white text on black background or different things that are just… You never think it’s tough enough with decent eyesight to deal with some of them, so anybody with any vision disability, yeah, the contrast would be huge. Excellent points.

The future of shopping and accessibility

Bob: Do you have any foresight into what may be the future of ecommerce and accessibility? Anything that you see in the works, or they’re trying to solve a certain issue? Something that we might be seeing on the horizon?

Devon: One thing that’s come up a few times in the past year or so, basically other platforms, in general. Everything from kiosks to being able to shop on maybe your TV. Just thinking about being more platform agnostic—not thinking about your website as being the sole place. If you have a mobile app, that includes you. In general, thinking about all these other devices that we have now that are also computers. So I’m thinking of TVs, smartphones, the internet of things, Alexa, Amazon’s robot that lets you order things just by talking to it. Just in general, thinking about all these technologies that are being built to be able to get people to buy things when they think of them, using whatever platform they’re currently on, are also great opportunities for making accessible shopping experiences for users with disabilities. Because you’re broadening people’s options for doing any sort of interactions with technology that are either just their preferred way of doing it, or just make it easier for them to do those things. I think in general being more device agnostic and thinking about: “What are the different ways that we can bring whatever it is we’re selling or providing to people on different platforms?”

Bob: I just was reading an article recently, and it kind of throws another whole wrench into things because somebody was talking about the next big thing in ecommerce is going to be virtual reality. As you’re talking about this I’m thinking, “Boy, how does that play into accessibility?” That’s an interesting one, any thoughts on that?

Devon: I guess it’s funny because I feel like yeah, VR was very big this year, which comes up every once in a while, like every 10 years, but we actually have technology now that supports it in a reasonable way. Yes, I think we will totally be shopping in virtual reality. Why not? We’re shopping on everything else. I think for folks with mobility issues it could be huge. I’m just thinking off the top of my head now. I think there’s opportunities for doing augmented reality type experiences for shopping in a physical space, as well, or providing someone with a sort of physical shopping type experience through virtual reality. I think there’s just a lot of opportunities for providing information to people in different ways.

Bob: Yeah, it’ll be interesting to see how that all plays out. You’re right, it’s something that keeps cropping up and stuff. We’ll see where that goes.

Where to start

Bob: Okay, so before we get into some other questions here I have for you, anything I’ve missed or any other nuggets you share with us around accessibility?

Devon: Usually the questions I’m asked are: “What is accessibility? Who does it affect? What can I do to make my site or app accessible? What are some quick tests I can do or quick things I can do?” I think it’s becoming clear to a lot of people that there’s not an easy fix. A place to start that we often recommend is: if you’re just starting out with accessibility or you don’t know how accessible your site is is to focus on keyboard support, making sure your app or website can be used with a keyboard. Makes it available to anyone with motor or dexterity issues, as well as anyone that uses technologies like screen readers. That’s huge population, that’s people with arthritis, that’s people with any sort of muscular issues. That’s a lot of people. Keyboard support is super important.

Support for images in media. If you’ve got any sort of image-based content or videos or anything like that on your website, making sure that those things are accessible. Having text alternatives, having captions, things like that. A lot of those things have gotten a lot easier if you’re using YouTube or one of the other larger third-party video websites. They make it really easy to make captions, so that can be a huge help to users.

The other thing is forms. We talked about forms a little bit. On a good day, forms can be really difficult for everyone to use, so making sure that your forms are implemented following web standards. Making sure that your labels are all correct. Making sure that it’s really easy for people to fix errors if they’ve made errors. Making sure that the states of things are really clear. That’s usually the last thing someone is doing, too, in a shopping experience. They’re filling in their credit card and they’re filling in their address and stuff, and so you don’t want them to abandon what they’re doing because you made it hard for them to type some stuff in a box. Forms are super important to you. Those just are the big three things we tell people to start with.

Bob: Yeah, and that reminds me, actually, that I do need to get transcripts for my show. I’m feeling very guilty right now and I didn’t know that.

Devon: I’m sorry, that wasn’t my intention.

Bob: No, that’s good, I need a reminder.

Online shopping with your friendly neighborhood accessibility specialist

Bob: I’m going to have you answer a few questions as an online shopper to kind of wrap up this show. We are going to have you put on your online shopping hat when you’re off work and you’ve got all this money to spend that you’re making all the time. I’m not sure how much you shop online, but I think we’re going to find out. I know that you, as somebody that works in accessibility, this could play into the answer to this question, but as an online shopper, what is the biggest frustration you come up against when you’re shopping online that you see time and time again?

Devon: I hate to bring up forms again, but forms.

Bob: Forms.

Devon: I use 1Password for storage and keeping track of credit cards and stuff because I can’t remember anything. Often it’ll be a new website I haven’t used before and I’ll go to use 1Password to fill in my details and it doesn’t work, so I have to go and look. Usually it’s because the form isn’t implemented in an accessible way. It’s not programatically correct. The labels aren’t tied to a field, maybe the fields aren’t even real. HTML form fields might be custom ones and the other ones, they’re just doing everything with JavaScript. You never know. That’s the frustrating thing for me when I’m trying to get through a purchase path is that I can’t use the tools I need and try to reduce my stress in filling out a form. That’s the biggest thing I think for me is forms.

Bob: You have a thing for forms, don’t you? I’m just kidding.

Devon: I do! I spend a lot of my time looking at forms!

Bob: Oh, I bet. Sounds like it. I’m going to hide all of my forms from you from now on. Please don’t go to my site, please. Is there anything that’s available online that you would never buy online, that you have to buy in person?

Devon: I’ve thought about this for a while. I can’t think of anything. I think there are a few factors. I work at home and I don’t drive a ton, so just having things mailed to me is very convenient. I also live in Seattle, so I live in like Amazon town. I feel like in general I just live in a very online shopping centred culture. It might also be my age. I’m in the latter days of millennials so I have had a very web-centred life in general. I book appointments online or via text. When we were shopping for a house, we were like, “Wouldn’t it be nice if there was just an online house store we could go to?” It’s the real estate agent. I can’t think of anything. I don’t think there’s a genre of products I can think of that I wouldn’t want to buy online.

Bob: Last, if you could start your online store and it didn’t matter—time, money, resources, none of that really mattered—you just would love to sell something online, whether it sells tons or not, just because you would enjoy doing it…is there anything you can think of?

Devon: My beginning in web work was in online publishing, academic publishing, actually. I’ve always had a soft spot for online publishing and online people that write stuff, whether it’s stories or games or anything—being able to sell the things that they make. I think I would want to do something along those lines. I don’t know if it might be my own stuff, might be other people’s work, but some sort of online content, I guess. Fiction, non-fiction, I think that would be it.

Bob: I bet you all the forms would be just so incredibly…

Devon: They’d be spectacular.

Bob: Yeah, they’d be the best forms on the web. We would just come to your site and get stuff just because we’d want to use your forms. I just know that would be it. Well boy, I think this is great. This is, like I said, a topic I’ve been wanting to get somebody on to talk about. I know we could probably go on and on forever, but I think you’ve covered quite a bit and it’s going to really help our listeners. I just want to thank you for taking the time to be our guest today.

Devon: Thank you so much for having me.

Bob: You bet. Until we meet next time, remember: we all need to believe in a digital world for everyone. As a listener, I ask you to learn more about how you can join in to help the web become more accessible. And of course, don’t forget, every Wednesday, to do the Woo.

The post Ecommerce and accessibility: Do the Woo podcast interview with Devon Persing appeared first on Simply Accessible.

Flying the accessible skies: reflecting on progress in the airline industry Thu, 07 Jul 2016 20:24:34 +0000 For the last several years, Simply Accessible has been honoured to help several airlines develop their accessibility programs in response to the US Department of Transportation (DOT) ruling to include airline digital content in the Air Carrier Access Act (ACAA). The Phase 1 deadline has passed and we’re proud of how far our clients have come.

The post Flying the accessible skies: reflecting on progress in the airline industry appeared first on Simply Accessible.

First, a bit of context. When the DOT amended their ruling in the ACAA, we were contacted by a number of airlines looking to improve the accessibility of their websites. The ACAA requires airline companies to make their web site content accessible. The DOT split the work into two phases, with the first phase to be completed by mid-December of last year—a deadline extended to June 30, 2016 after IATA (the International Air Transport Association) requested more time to allow air carriers to comply.

For Phase 1, airlines needed to make sure the web pages associated with seven core travel functions (like booking a reservation or checking in for a flight) conformed to WCAG 2.0 Level AA. But beyond that—and most exciting for accessibility advocates like us—the ACAA requirements didn’t stop at technical compliance. Air carriers also had to do usability testing with people who experience visual, auditory, tactile, and cognitive disabilities to ensure their sites were truly accessible.

It has been an honour, a privilege, and one hell of a journey working beside our airline partners to reach the June 30th deadline. This milestone marks the beginning of a new standard and quality of online user experience for airline passengers. Our clients have made great strides towards creating more accessible web sites, and our team has been with them every step of the way: working long and unusual hours, staying patient and persistent, and continually insisting that people remain at the forefront of what we’re doing on the web.

So today, a week after the deadlines, we’re pausing to reflect on the biggest challenges airlines faced leading up to this first ACAA deadline, and what impressed us most about the work our clients did.

Complex sites, legacy code, and huge codebases

I honestly think the biggest challenges the airlines faced was the sheer complexity of their sites. They have to reliably process millions of tickets with dynamic information, flight times, prices, etc. It wasn’t that our clients had so many issues as much as it was that they had so many pages (and states of pages, and sub-states of pages, and sub-sub-, well, you get the picture) to work on!

What impressed me most was that they managed to make so many fixes in this extremely dynamic environment. It’s not a situation in which they can simply fix a minor problem; it’s got to work across any of a hundred things that can happen to the same page depending on a lot of factors. What also impressed me was the absolute depth of knowledge of the teams. Their developers could rattle off subsections of their site as if they’d been looking at it an hour before. Additionally, their Product Owners also displayed an awesome and intricate understanding of the complicated nuances within their system. —Charles

Airlines typically have multiple vendors that manage different parts of the user’s experience. Content that “looks” the same in booking and check-in, for example, might be owned by two different vendors. Airline clients had to not only integrate accessibility improvements into their own content, but had to work with vendors to have similar changes implemented.

Our clients made huge systemic changes across their entire site, often across thousands of pages, improving the experience for millions of people. I think looking into their own processes and evaluating what’s most valuable to their customers helped their efforts toward accessibility but also helped them to better understand their audience and their needs. —Devon

I think the sheer volume of the task at hand was our clients’ biggest challenge, especially when accessibility is something most teams were new to. Airline websites aren’t small and almost every page had to be organized and managed while it went through the entire process. There was a lot of difficult coordination required to get all the pieces in place. They’ve clearly tried to take our recommendations and advice on when moving forward with new design and development. It’s not always perfect, but building for accessibility has become part of their thinking which is half the battle. —Stuart

I supported an airline vendor team with clinic calls who had to overcome legacy markup integrated with an existing system. With legacy code, changes that would be simple to do in a recent build were more complicated to achieve. They had to think hard about the goal of each accessibility criteria in order to find solutions that fulfilled their users’ needs. This was a big job, and I was really impressed by their steady pace. If they’d thrown themselves into the deep end, they’d have burned out long before the deadline. But, they came up with a sustainable schedule and worked hard to keep up with it. I think they all deserve a long holiday. —Julie

Building a process and a practice

I think the biggest challenge that our clients faced was the learning curve of how to implement accessibility best practices. Many clients had a variety of applications with quite a span of legacy code bases that needed to be fixed up—each posing its own challenges to make usable for for all kinds of folks.

I was really impressed by how so many people embraced the work and took it as an opportunity to learn. I think the greatest moments in our ACAA projects were getting to watch as things started to make sense for our clients—the moment they got it! —Gavin

The biggest challenge that I saw our airline clients wrestle with over the last year was one of scaling and maturing their web production lifecycle. Integrating accessibility into all of these existing workflows often revealed gaps and outdated processes. Transformation naturally happens at different speeds within various teams. But, in 2015, accessibility acted as a roll call for all airline teams, requiring everyone to embrace a huge paradigm shift together.

I was incredibly impressed by the level of commitment that airlines had to involving people with disabilities into the work they do. Airlines who already had usability testing integrated into their process had to expand the way they conducted studies, and they were eager to learn how to make this critical practice sustainable and agile to match the cadence of their development teams. And, those who had never really done much usability testing before immediately understood the relevance and significance of real user feedback. —Elle

By far, the biggest challenges our airlines faced leading up to this ACAA deadline were twofold: managing the complexities of the third-party vendor systems that are required to integrate into their web sites, and having to learn rapidly, studying and fixing one part of their site and applying those insights and skills to other parts.

What impressed me most was how teams stuck in and did the work. In order to do that, they were in a near constant state of prioritization—understanding impact of barriers on people with disabilities as they related to the deadlines that the ACAA set forth. Understanding that the core travel functions come first—not because of something arbitrary, but because pages and functionality related to the seven core travel functions include the user tasks that are of the most value to passengers. Building that skill of prioritization was key, and each one of our clients took that skill on across the board from executive leadership to writers, designers, developers, and QA testers. —Derek

Accessibility as usability

Our clients were faced with a huge task: to understand that some of the common development practices they’d used throughout the site can create accessibility barriers for users. Widely-used components such as custom form elements, datepickers and seat-selection interfaces had to be revisited to ensure they worked for all users. In embracing this challenge, airline teams came to understand how it’s necessary to put yourself in the position of different kinds of users, and to gain an empathy for the way they interact with these components and the challenges they face. —James

One of the best aspects—from my perspective as our manager of accessibility and usability testing—was the integration of usability into the ACAA requirements. We didn’t just have to say these airlines’ sites were accessible, we had to prove that they were accessible.

After we completed some of the usability testing, our clients dug in and watched every minute of the recordings. For each client, this is more than thirty hours of video. Our clients got to observe people from varied backgrounds trying to complete tasks, including participants’ valuable play-by-play narration and feedback. It was the first time some of our clients got to see assistive technology like screen readers and voice recognition software in action. They’re carrying what they’ve learned into everything they’re designing and developing from now on. —Joanna

The journey isn’t over for our airline partners, but we’re proud of how far they’ve come and how they’re looking ahead to the next phase of the process. Our fearless leader has written that accessibility is a journey and a destination, so bravo to our airline partners! And we’ll stop just shy of making a ‘cleared for take-off’ joke.

The post Flying the accessible skies: reflecting on progress in the airline industry appeared first on Simply Accessible.

Passion in action: for Scott Vinkle, accessibility is a verb Thu, 30 Jun 2016 15:55:25 +0000 Meet Scott Vinkle—man of action, and the most recent addition to Simply Accessible’s assessment and development team.

The post Passion in action: for Scott Vinkle, accessibility is a verb appeared first on Simply Accessible.

Scott, the newest member of Simply Accessible’s dev and assessment team, uses his powers for good in a way that’s both inspiring and instructive. The Silent Mountain—he’s the tallest member of our team by far—takes everything that’s awesome about being a developer and throws it into making the web work better for everyone.

A man of action

Scott’s natural curiosity and hands-on learning style struck us all during our team retreat in February, just after he joined our team. We were sitting around debating how an error alert might interface with set of Philips Hue lightbulbs. (Yes, we chat about that kind of thing often.) We talked through various approaches, brainstorming different ways to tackle the problem. Fifteen minutes in, Scott pipes up in his quiet baritone, directing our attention to a large shared screen. He had worked up a demo, which he then refined over the rest of our retreat.

While the rest of us talked, Scott built.

It’s that brand of roll-up-your-sleeves curiosity that led to Scott’s accessibility awakening a few years into his career as a front-end developer. He installed a screen reader browser extension, not sure what to expect. Then, he heard it: a voice reading aloud the page he’d been working on for weeks. It was a revelation.

“Immediately, I had tons of questions: Is this is how some people experience the web? Is the code I’m writing correct for these other interfaces? Have I been doing it wrong for all these years? I felt compelled to learn everything I could, and I had to learn fast.”

Already well versed in responsive design, he realized that he had a responsibility to learn how to make sites usable for users with different kinds of abilities. Fueled by the fear that people were unable to use the things he’d made, he threw himself into the challenge.

He pushed for accessibility and responsive design within his company, but they ignored him. Galvanized to learn more, Scott educated himself under the radar and did his own testing.

More doer than talker, Scott didn’t make a big deal out of his shift to accessible developer. “It’s the right thing to do anyway. I’m not going to ask permission,” he shrugs. It also made for some pretty late nights. “They’d give me a deadline and I’d do everything I could to make the interface the best it could be. If it meant long hours, so be it.”

That’s Vinkle’s style in a nutshell.

First, you build it. Then, you share it.

Since then, he’s been leading by example, contributing CodePen links to the patterns page and the broader online community of developers. He also co-organizes the CodePen Ottawa monthly meetup.

“Bringing knowledge back to the community is important so people know how to implement things properly. I’ve benefited from it, too—the front-end community is so willing to share how to implement new techniques. Contributing to the body of accessibility knowledge is my way of giving back to the community I’ve learned from over the years.”

His role at Simply Accessible is a critical one. In addition to the development work he does, Scott’s also part of our assessment team, which thoroughly tests our clients sites for accessibility issues. But here at SA, assessment isn’t just assessment. It’s an opportunity for growth and education. “We bring our clients awareness about issues that impact people’s daily lives. Users often depend on these websites—we help our clients see where people have difficulty or where the sites are impossible for someone to use. On the flip side, we show them how potentially easy these issues are to fix and we help them get there.”

We’re thrilled to have Scott’s passion-in-action approach on our team, benefitting all of our clients, and all of us.

“It’s not really accessibility that we need to keep in mind, but people. People are why we do this. If they can’t use what we create, why create at all?”

Look forward to more of Scott’s hands-on wisdom on our blog in the coming months!

The post Passion in action: for Scott Vinkle, accessibility is a verb appeared first on Simply Accessible.

Going agile: transforming how we do things at Simply Accessible Thu, 23 Jun 2016 15:49:05 +0000 We’re coming out of the closet: Simply Accessible is agile! We’d love to introduce you to the smartie guiding us through the transformation.

The post Going agile: transforming how we do things at Simply Accessible appeared first on Simply Accessible.

Charles CallistroWe write introduction posts for the new badasses who join the Simply Accessible team—but this particular badass has been with us for quite some time. Charles Callistro has been SA’s scrum master since 2013, but it’s only recently that he joined the leadership team, taking the role of Agile Coach, and officially guiding us through an agile transformation.

“We’ve found that being agile, internally and externally, works better than any other process we’ve tried,” Charles explains. “We’ve worked in an agile framework for many years here, but we’re now going all the way and applying agile methodologies to everything we do.”

Traditionally, agile starts in the IT department and doesn’t extend beyond it. So the developers are agile, but marketing and leadership, for example, are still building requirements upfront or in a vacuum. Simply Accessible is doubling-down and incorporating agile throughout the company, even including our hiring process and editorial.

“We believe that the agile processes are of benefit beyond iterative software—people just work together better this way.”

Our agile awakening

Charles’ own agile transformation happened two years ago after a conference. He invested in scrum master training and became an advocate for agile internally here at Simply Accessible. Derek and Elle took Product Owner training and that clinched it. Since then, we’ve been transforming every aspect of how we do our work, both internally and externally, to get agile minded, nimble, and more efficient.

“Agile and accessibility are both paradigm shifts at an organization—they’re each really about putting the user first. When done poorly, they’re frustrating and costly. When done well, they’re transformational and game changing.” – Elle Waters, Director of Strategy

“Agile transformation never ends, but we’ve hit lots of milestones,” Charles says. “We’re embracing the process, and we’re finding more of our clients using this methodology, too. Our workflow meshes with our clients’ more seamlessly now. Communication is easier. Things can change rapidly without a lot of impact on either side.”

“Agile process and practice makes us constantly think about what is most valuable to our clients, and more importantly…most valuable to their clients.” – Derek Featherstone, Founder and Team Lead

Since agile transformation is an ongoing thing, the role of Agile Coach fits perfectly with the constant iteration and improvement implicit in the methodology. It also fits with Simply Accessible’s focus on teaching and learning. Charles says, “My job is to convince people that agile is going to help them and then partner with them to make it happen.”

Agile editorial: a case study

Charles also says I’m the poster child for that here at Simply Accessible, and I have to agree.

During our team retreat in February, Charles led daily agile sessions with the team. I had heard of agile, but had no hands-on experience with it, so this was my first real exposure to the methodology and how it works for teams. Through Charles’ sessions and taking a deep look at our internal processes, I had my own agile awakening. I saw immediately how agile could benefit our editorial workflow, get the whole team engaged with our blog, and produce content more efficiently.

Since February, we’ve gone from squeezing blog posts out of already-taxed developers and our assessment team to accelerating our publishing schedule, working collaboratively across departments, and at one point being seven posts ahead of schedule. As an editorial strategist, I couldn’t be more amazed or thrilled with the results.

Agile editorial allows us to stay responsive, pivoting posts based on what’s urgent for our clients or our community, adapting the scope of our posts to current workloads, and improving our process as we go.

Agile and accessibility

Agile also melds well with Simply Accessible’s approach to accessibility. We need to have the ability to adapt to change, as human beings and their needs change.

Many clients come to us with accessibility guidelines in mind. But our perspective, and our criteria for success is: does this work for someone who needs it? Truly usable accessibility has all kinds of nuance and it changes every day. “With agile, we can keep ‘is this working for people?’ in the forefront,” Charles explains. “The requirements aren’t the focus, people are the focus. Agile lets us keep the focus on the people.”

“Agile, for me, is a more humanistic approach to business organization. It ties into UX and usability testing, and other things we value. It’s a people-first philosophy—and the best fit to match our core values.” – Charles Callistro, Agile Coach

We’re lucky to have someone as passionate as Charles leading the charge of our transformation. Look for more posts about agile accessibility in the months to come. We’re excited to share what we’re learning with you!

The post Going agile: transforming how we do things at Simply Accessible appeared first on Simply Accessible.

Accessibility is everyone’s job: a role-based model for teams Thu, 16 Jun 2016 16:00:15 +0000 In order for projects to be truly accessible, the whole team needs to collaborate. But, who does what? In this post, Mark helps us unpack how each role can contribute to making something that works for everyone.

The post Accessibility is everyone’s job: a role-based model for teams appeared first on Simply Accessible.

It’s tempting to think that accessibility is for developers and accessibility specialists. That’s how it’s commonly viewed in many organizations. For large organizations, it’s convenient to think: Accessibility is a technical thing, so let’s leave it to the technical team. We’ll decide what we’re building, and those folks will make it work for everyone and everything, right?

Not exactly.

If everyone works on the assumption that a product’s accessibility is solely the responsibility of developers or specialists, then these same developers and specialists can find that even with the best will in the world, they can’t produce an accessible end product. Why? Because decisions have been made (or not made) throughout the project’s lifecycle which make that impossible to achieve.

Producing an accessible product or service requires input and buy-in from all the colours of the corporate rainbow. The development skills needed to build an accessible website are of little use when the project doesn’t have the cooperation of other teams outside of the IT space.

For accessibility to become embedded as best practice in an organization, all team members have to understand the part they play in producing a product which everyone can use.

Initially, it can be a challenge. You can have a development team full of accessibility superstars, but if the marketing and brand folks are running with corporate colours of pale blue on a light grey background, or you don’t have access to assistive technology to check what you build, then you’re on the back foot from the get-go.

The need to create sites and applications accessible to people with disabilities shouldn’t be surprising for anyone on the team. If teams, or parts of teams, are unaware of accessibility’s importance, those that do get it need to help their colleagues understand. For an organization to successfully create an accessible experience for its customers, everybody should strive, both in their own teams and as part of the wider team, to ensure that people with impairments are considered.

But what part of the accessibility spectrum does your role bring to life?

Marketing or online brand team

If you work in the marketing and design team then you take responsibility for the accessibility of all the brand elements, including corporate palette, typeface and language used. That should extend to any external agencies you commission, too. If any external agency produces brand and style guidelines for you, they need to be aware of the impact of creating inaccessible content and that accessibility is a key concern for you, their client.

The marketing and online brand team also needs to work closely with the UX team and the developers to ensure that any changes they make to global styling or brand doesn’t negatively impact accessibility, and that the two teams aren’t heading in different directions leaving developers wondering exactly which style or design pattern should be used.

Content team

Teams producing content for the web represent a really critical link in maintaining the accessibility of a site. Often they’re responsible for interacting with content management systems, adding images to the site, and creating link text. It’s not uncommon for this content to bypass formal testing, and the good work you’ve put in increasing the accessibility of your site can slowly start to leak away if you’re not careful.

It’s important that as a content team, you’re aware of how to optimize content for people with impairments. Tone and corporate voice are often clearly prescribed for brochureware sites, for example. Equally important is the heading structure within content, and the need to write content at an accessible reading level. Also, the ability to add key semantic HTML tags and elements to content should be a prerequisite when procuring a content management system.

Project management

Project managers need to allow time for the team to check for accessibility issues, to raise bugs, and to fix and retest any issues found. It’s not sufficient to identify accessibility issues as ‘enhancement’ in a ‘Phase 2’ development which might never see the light of day. Ideally, accessibility is part of the project from its initial planning and budgeting stages. Project managers have a great opportunity to advocate for accessibility from the ground up.

As project manager, it’s essential that you create an environment where accessibility issues aren’t considered to be bugs, but key features which have been incorrectly implemented and need to be resolved.

Software testers and QA teams

Testers should know how to spot basic accessibility issues. Not to the level that an accessibility expert could, but they should be able to test for obvious issues like keyboard accessibility, text alternatives, and basic colour contrast—even if they don’t necessarily know how to resolve these issues.

However, in most organizations, accessibility testing isn’t something that is currently considered part of the testers skillset or role profile. To integrate accessibility awareness into the test team, the project manager should make sure that they are given the training, time, and autonomy to be able to raise accessibility bugs in the testing phase.

Security and procurement teams

Security and procurement teams perform a very important role within organizations, but they can also be a huge blocker to accessible design and development. These teams need to quickly authorize the tools an organization needs so they can validate and maintain the accessibility of its website. Some assistive technologies, such as JAWS, are expensive, but others are free or low-cost. These tools are critical for testing and validating a site’s accessibility. It won’t help if purchasing screen readers or any other assistive technology is subject to a months-long procurement exercise.

For the security team, approving software that can quickly and easily carry out usability tests remotely is central to the success of any project.

UX team

User experience designers are the champions of accessibility in the team. They should ensure that accessibility is a priority—and that it’s implemented correctly. They also spearhead usability testing, making sure it’s done regularly with users who have a range of disabilities, and who use a range of assistive technologies. They should provide support to all other areas by educating teams on how best to improve their part of the product to create better experiences for users.

The UX team should embrace the role of accessibility evangelists, acting as the gel holding all of the disparate corporate strands together.

Accessibility is everyone’s responsibility. If a single piece of the puzzle is missing, it becomes significantly more difficult to create and nurture a lasting accessibility culture within an organization.

How have you integrated accessibility into your organization? What strategies worked to bring your teams together? Share your experiences in the comments below.

The post Accessibility is everyone’s job: a role-based model for teams appeared first on Simply Accessible.

]]> 1
Aprés-GAAD: how we spent our Global Accessibility Awareness Day Thu, 09 Jun 2016 16:00:13 +0000 Our global team spent GAAD 2016 generating homegrown awareness in our various locales around the world. Our reports will continue to flow in over the next several weeks, but here’s how a few of Simply Accessible’s team members spent their Global Accessibility Awareness Day.

The post Aprés-GAAD: how we spent our Global Accessibility Awareness Day appeared first on Simply Accessible.

From Western Australia to Eastern Canada to Hawaii, here’s how four of us rang in GAAD 2016.

Julie Grundy – Perth, Western Australia, A11y Bytes

Julie presents on The Accessibility Ecosystem. Her headphones, attached to her phone, are draped around her neck as a mic for the live captioning.This year for GAAD, I hosted Perth’s inaugural A11y Bytes event, and I’m thrilled to report it was a success! We had over thirty people attend, and many told me how much they enjoyed the variety of speakers and the practical advice they received.

I saw lots of people introduce themselves to each other, making connections and sharing information, which is wonderful. Our venue, VisAbility, gave a box of chocolates to the team who could translate a Braille phrase the quickest. It was fun to see everyone putting their heads together.

I spoke about the Accessibility Ecosystem. The talk was inspired by a little thought bubble I had about how eco-activism’s “think global, act local” philosophy is a useful metric for accessibility, too—especially if you’re new to it and overwhelmed by all the things that need to be done. We did live captioning for all the speakers, which worked really well, although in future I want to use a bigger screen to display it in addition to using people’s own smartphones and tablets. I’ve heard from friends and colleagues that the A11y Bytes events in Sydney, Melbourne and Canberra were also well attended and great fun.

Gavin Ogston – Ottawa, ON, a11yYOW

I attended A11yYOW here in Ottawa and chatted with local devs about the challenges they’re facing right now. I was curious about the biggest hurdles they face with web accessibility, on any front: tech, knowledge, company buy-in, time, resources, etc. What I discovered in my conversations was that there’s often a knowledge gap between business leaders and IT, where the business folks don’t always fully understand the implications of creating an accessible site.

Often organizations have difficulty judging whether the services they adopt from providers are accessible—even when told they’re accessible—and, more to the point, whether they’re even usable. Then, teams find themselves locked into systems they can’t customize or adapt to make them, or their products, accessible in the way they want. I also heard a lot from developers that they often feel overwhelmed just trying to stay up-to-date with web technologies, let alone accessibility.

We all agreed that events like Accessibility Camp Ottawa are very important as they provide a space in the community where people can find out more about accessibility best practices and, maybe even more importantly, connect with others who can help them find the resources and solutions they need.

Nicolas Steenhout – Montreal, QC, Apple Store

Nic presents in French to Apple store customers and staffOn May 19th, I spoke to staff and customers of the Apple Store in Laval, introducing several concepts about accessibility and assistive technology.

We spoke about how technology can make a huge difference in people’s lives, and how many tools that were initially designed to help people with disabilities have found their way into everyday products (like text-to-speech). We also discussed how technology doesn’t have to be specifically adapted to people with disabilities to be helpful—like using a tablet for communication instead of an expensive dedicated communication board.

Participants had great questions after my presentation. For instance: “How do site owners know that their site presents barriers? How would they go about solving these issues?” I spoke about the fact that some people with disabilities, but not all, will contact a site to let them know they’re encountering barriers. Often a visitor with a disability will move on to another site or service provider. I emphasized that it’s up to the owner to be proactive and assess their own site. Starting an accessibility practice—or connecting with companies who specialize in accessibility—will help ensure that sites are usable by all who visit them.

It was so satisfying to be a part of this event and generate some awareness in a retail space, which was very new for me. We’re looking at doing it again next year!

Kara VanRoekel – Keaau, HI

I had some good discussions with members of the local developer groups on various online channels throughout the course of the day. I asked them what they did to support accessibility on the sites and products that they work on, as well as what they find most challenging about designing and building with accessibility in mind.

Most of the people I talked with said they did their best to use what they call “good code”: semantic markup, appropriate page titles, correct use of headers, and no deprecated tags. While a few people thought that “good code” should be enough to render any site or app accessible, most admitted that they knew they could be doing a lot more to support accessibility, but weren’t sure what they should be doing. These devs were afraid to make mistakes and accidentally make things worse.

A lack of knowledge about accessibility was what almost everyone that I talked to found most challenging. A number of people had heard about ARIA, but weren’t sure where or how to implement it. Many people knew that images should have alt attributes, but weren’t sure why (other than “It’s just what you do”). I ended up fielding a lot of questions about screen readers, colour contrast, keyboard use, and app accessibility, among others. Everyone wanted to learn more—they were genuinely curious about what they could do with their projects to make them more accessible.

Before GAAD, I had already been asked to do a screen reader demonstration at an upcoming meeting. After GAAD, I was contacted by several members of the meetup group to say that they were looking forward to my presentation, and would have some additional accessibility questions for me! I’m thrilled that my fellow devs are interested in learning more about online accessibility.

Stay tuned as we bring you more follow-up reports from our various GAAD adventures: from visiting a printing press for the blind to presenting to a class of student developers!

The post Aprés-GAAD: how we spent our Global Accessibility Awareness Day appeared first on Simply Accessible.

Accessibility’s new chapter: a report from AccessU 2016 Thu, 02 Jun 2016 15:46:40 +0000 Devon and Elle presented at the annual John Slatin AccessU conference last month. Devon reports back on an exciting culture shift unfolding in the accessibility community.

The post Accessibility’s new chapter: a report from AccessU 2016 appeared first on Simply Accessible.

Earlier this month, Elle Waters and I had the pleasure of speaking at the annual John Slatin AccessU conference in Austin, TX. Attendees from higher education, nonprofit, government, and private sectors spent three days learning about designing, developing, testing, and planning for accessibility, as well as celebrating twelve years of learning and community at AccessU.

When I wasn’t teaching sessions on QA testing and mobile development, Elle and I worked to answer the following question: If accessibility is a story, what’s the current chapter? I took a high level look at what attendees and speakers were talking about, and what questions they were asking, to understand where we’re at in the accessibility narrative.

At Simply Accessible, when we start working with a new client, they’re often just beginning their accessibility journey. Our first step is usually to do an assessment, followed by partnering with teams to remediate and prevent future issues, and to help them understand the important role of accessibility with their customers. The last step is often the hardest: to create a sustainable, systemic approach to accessibility that touches all parts of the organization. You can imagine our delight when it was this last step that came up over and over again in sessions and in conversation at AccessU.

Folks we talked to were largely past contemplating “Why is this important?” and were deep into grappling with “How are we doing this?”

Turning the page to program-level accessibility

There are a few reasons for this culture shift toward building sustainable accessibility programs:

  • Historically, higher education and government organizations have had more oversight regarding accessibility, so they’re already primed for (and making) program-level changes. Their newest challenge is extending that support to the ever-growing digital products and services they provide their users, ranging from distance learning to working with students to create, manage, and understand user-generated content.
  • When private companies engage with government agencies and similar groups that have accessibility requirements, they’re building at least some accessibility features into their products. To keep down costs, it makes sense to integrate those changes into parts of their mainstream product instead of creating and maintaining separate products.
  • Members of all sorts of teams already recognize that there’s no one-size-fits-all solution for making products and services. They’re also coming to understand that there’s no one-size-fits-all way to approach their work, and accessibility is part of that. As organizations continue to wrestle with accessibility over time—as resources, budgets, and organization focus change, not to mention technologies and techniques—they’re realizing that accessibility practice needs to be just as flexible as everything else they do.

Across sessions we ran and attended, questions related to building sustainable programs came up again and again. Folks seem to agree that from an implementation perspective, baking accessibility into component libraries, code standards, UX documentation, and QA practices across products and services is key, as is doing testing with real users who have disabilities.

The plot thickens

From there, however, attendees entered more complex territory. Folks in all sorts of roles knew broadly what they needed to do—engage in universal design principles, write standards-based code, do functional testing, get user feedback—but they struggled with how or where to start.

Technologists, designers, and product owners are unsure about what user impacts to prioritize; they’re concerned about not having the authority to make changes at an organizational level; and they’re uneasy about how to train everyone. They’re worried about what they don’t know, and afraid of what they can’t get done.

On paper, starting a sustainable accessibility program looks a lot like moving from waterfall to agile: it’s about transforming each aspect of how work is done, with the goal of producing more—better and faster—for users. I asked Elle why accessibility was seen so differently from an agile transformation. From her perspective, the challenge with accessibility, and perhaps the main source of anxiety, is that it’s not simply about process.

“Accessibility isn’t really a process problem—it’s a people problem.” – Elle Waters

Accessibility requires buy-in, finding allies, getting feedback from users, and recognizing the multi-channel journeys your users go on every day when they use your products and services. A successful program is more than clean code and good documentation: it’s the relationships and hard, collaborative work that happens between the people who practice accessibility and everyone who benefits.

So, what chapter are we in with accessibility? Well, the story of accessibility as a technical problem has been told and many people know the words by heart. Now, we start the hero’s journey to sustainability.

Over the next several months, we’ll share more about the challenging road to sustainable, systemic accessibility, offering those willing warriors the training they’ll need along the path.

The post Accessibility’s new chapter: a report from AccessU 2016 appeared first on Simply Accessible.

Should all content be responsive? Thu, 26 May 2016 15:00:20 +0000 In this screencast, Derek walks us through a couple of examples where traditional approaches to responsive content may actually hamper people from achieving their goals online. He proposes some alternative approaches that keep user experience top of mind.

The post Should all content be responsive? appeared first on Simply Accessible.

One of the main benefits of responsive content is that it flexes to the browser’s viewport width so it’s easily consumed on different sized screens. But is this always the best approach? In some cases, scaling and flexibility may make the content harder to perceive. As always, it’s important to consider how people actually use the content to achieve a goal or complete a task.

User experience is our gold standard for judging any solution’s effectiveness.

In the following screencast, we take a look at two scenarios where approaching responsive content differently makes it simpler for users. The first example we look at is an image containing a lot of visual detail and information. The second, and our main focus, is tabular data where being able compare different data points or ranges of data is important. While you’re watching these demos, think about the impact that changing the display has on someone’s ability to compare data.

Feel free to download the transcript (txt).

Comparison is key

While we can maintain at least some sense of semantics in a responsive layout for tables, making sure people can still compare data relationships is critical, especially in the following use cases:

  1. Think of a person using a screen reader to compare a value in a cell to the value directly below in another cell. That might only take one keystroke in a full table, but when that same table is viewed responsively in a stack, that person may need to hunt a lot more to to get the same data.
  2. For someone with low vision who uses screen magnification, those same two adjacent table cells may now be hundreds or even thousands of pixels apart in a stacked layout.
  3. Someone who needs that visual two-dimensional grid to make sense of the data from a cognitive standpoint may really struggle trying to understand the data when we turn that table into stacked sets of name value pairs.

In cases where the visual display of something is fundamentally important to completing a task, we need to carefully consider how best to change the display (or perhaps not change the display) of that content. We’re looking forward to testing these approaches on real sites with people with disabilities. In particular, we’re curious about how the pop-out approach works for tasks like getting at details in a content image, or examining data points in a table.

Have you seen situations where a traditional responsive approach doesn’t seem quite right? Or actually makes completing certain tasks more difficult? Share your experiences in the comments below.

The post Should all content be responsive? appeared first on Simply Accessible.

]]> 1
Global Accessibility Awareness Day 2016, Simply Accessible edition (part 3!) Thu, 19 May 2016 19:38:32 +0000 Our worldwide tour of Simply Accessible's international team takes us to the Pacific Coast and beyond as we celebrate Global Accessibility Awareness Day 2016.

The post Global Accessibility Awareness Day 2016, Simply Accessible edition (part 3!) appeared first on Simply Accessible.

Here’s what our folks on the west coast are up to to celebrate Global Accessibility Awareness Day 2016. We’re also getting some end-of-day reports in from our pals in Greenwich Mean Time. It’s been a full day of rich conversations, accessibility adventures, and hometown awareness-building for GAAD 2016!

Kara Van Roekel – Keaau, HI

A photo of Hilo, Hawaii at dawn, courtesy Keoni Dibelka.

Given that Hawaii is well known for surfing, diving, sea-kayaking, and all kinds of water sports, I wanted to look into accessibility-friendly tourism and tourist activities.

During the course of my investigations, I was pleased to find that Hawaii, particularly Honolulu on Oahu, is fairly disability friendly. Almost all hotels are fully accessible. Most museums, attractions, and historical monuments offer special tours and access to people with disabilities.  Even many beaches and parks are accessible.

An organization on Oahu that really excited me was AccesSurf, whose goal is to help people with physical or cognitive disabilities to surf, paddle, and otherwise enjoy the water. Their monthly “Day at the Beach” activity is open to everyone, locals and tourists alike, with AccesSurf providing specialized equipment and trained volunteers to make sure that everyone can get in the water. Because of their proximity to the Pearl Harbor Naval base, they also have a monthly “Wounded Warrior” event that focuses specifically on injured or disabled military personnel. They’re even hosting an adaptive surf competition this summer.

I’m talking with AccesSurf, as well as with the local developer meetup group, about how their work intersects with web accessibility: what steps do they take to make sure the people who are trying to find them or learn more online can do so without barriers? I’d like to get people talking about what they know about designing for accessibility, what they don’t know but wish that they knew, and the importance of including accessibility in website design.

Joanna Briggs – Vancouver, BC

Beautiful Vancouver, BC from the water.

I’m really excited by the Tetra Society here in Vancouver and one of their new initiatives. The organization was started in Vancouver to recruit volunteers who design and build custom devices for people with disabilities. All kinds of folks volunteer for them (engineers, woodworkers, etc) and the devices they design and create are for everything—they have a huge database of assistive devices they’ve built for household, mobility, communication, and way more. Basically, when they see a need, someone builds a gadget for it.  After one of Tetra’s own employees was hit by a car crossing the street in his electric wheelchair, they looked for ways to increase the visibility of people who use wheelchairs and scooters at night. Vancouver can be a dark and rainy place! There’s now a Kickstarter campaign, so they will be able to manufacture safety lights for anyone who needs to be more visible at night. To me, this is the best of inclusive design in action and it’s an example of some of the exciting work making Vancouver even more accessible. I first found out about the project at the Vancouver Accessibility and Inclusive Design Meet-up, a local group that meets roughly monthly. For anyone interested in getting involved, it’s a welcoming community and a great place to start.

Devon Persing – Seattle, WA

A photo of Seattle WA's skyline.

I’m involved with Ada Developers Academy, a software development training program for women based in Seattle, WA. Their goal is making tech more inclusive while teaching best practices for full-stack web development—and I’ll be working with the students to think about accessibility in front-end web development. In the past, ADA students have been excited and eager to talk about and integrate accessibility into their front-end projects, which goes in hand with the students’ community-minded focus. Women I’ve met who are just entering technology are excited about doing work that has a positive impact. Accessibility is a huge part of making software that impacts people’s lives for the better.

Stuart Langridge – Birmingham, UK

A photo of Birmingham UK's scenic canal.

I canvassed developers and designers here in Birmingham, and asked them this question: “What do you do, when building, designing, or working on software, to cater to assistive technology users?” I stressed that I was looking for honesty, and that they wouldn’t be quoted directly or identified, so they could be candid.

Everybody I spoke with said they used semantic markup and structured documents logically, which is an encouraging start. Beyond that, though, the prevailing view was that if you do the semantic thing, something else takes care of the rest of accessibility for you. Magic, possibly? Or browser engines?

Everyone admitted that they ought to do more on the accessibility front than they do. One developer relied heavily on Google’s accessibility tools to identify issues. Others assumed that users have extensions to provide page zoom or text dictation if they need it. One respondent (a game developer) specifically called out colour blindness as something they pay attention to.

So, steps have been made: People routinely build semantic websites now. They’re aware that this helps with accessibility concerns, and that there are tools to help assess how well they’re doing. But the real value, today on Global Accessibility Awareness Day, comes from one particular comment which echoed the thoughts of most people I spoke with: “Thanks for making me (and everyone else you sent this to) think about this!”

The post Global Accessibility Awareness Day 2016, Simply Accessible edition (part 3!) appeared first on Simply Accessible.

Global Accessibility Awareness Day 2016, SA Edition (part 2!) Thu, 19 May 2016 13:04:46 +0000 It's Global Accessibility Awareness Day! Follow along as our team generates homegrown accessibility awareness all around the world. How are you celebrating GAAD 2016 today?

The post Global Accessibility Awareness Day 2016, SA Edition (part 2!) appeared first on Simply Accessible.

In celebration of Global Accessibility Awareness Day (GAAD) this year, we’re taking to the streets of our own hometowns. And, that’s quite a few locales! Yesterday, we shared with you about the cool activities happening in Australia, Scotland, and Nova Scotia to build more awareness about inclusion. We have more team members’ local activities and more places in the world to share the message. Check out the rest of what’s going on!

Nicolas Steenhout – Montreal, QC

Apple store in Laval, Quebec

I’ll be giving a presentation today on accessibility and assistive technology at the Apple Store in Laval, QC. I’m excited to create some web accessibility awareness with non-developers—the folks attending will be Apple staff and customers, so, it’s a great opportunity. I asked the organizer, Louis-Philippe Morier, why it was important for Apple to sensitize people about accessibility, and how he thinks this event will make a difference.

Louis-Philippe: “Trop souvent nous prenons pour acquis que LA méthode pour accéder à la technologie est deux mains, deux yeux, deux oreilles.

Il est important de souligner les systèmes qui incluent d’autres méthodes d’accès, et informer que ces moyens existent. Pour soi-même ou des proches.

Il faut démontrer l’importance d’une technologie accessible afin qu’une souris et un clavier ne soient plus perçus comme la manière “normale” mais plutôt une méthode parmi tant d’autres pour accéder à sa technologie.”

And now in English:

“Too often, we take for granted that the method to access technology is two hands, two eyes, two ears. It’s important to outline systems that allow other ways to access information, for oneself or for loved ones. We must demonstrate the importance of accessible technologies so that keyboard and mouse are no longer perceived as “normal”, but a method among others to access technology.”

For anyone in the Laval area who wants to hear Nic speak, his presentation (which will be in French) is at the Apple Store, Carrefour Laval, 3035 Boulevard le Carrefour from 1:45 pm until 2:45 pm Eastern.

Alex Turpin – Gatineau, QC

A view of Gatineau, Quebec from the Ottawa River

I work in the office of my old employer, a web shop making mostly client WordPress sites. A few years ago, they started encouraging their clients toward responsive websites. It seemed to them that responsive should be baked in from the start, and not seen as an additional feature, what with so many people using mobile phones to access the web. I drew a parallel with accessibility to help them realize that this is a similar situation: accessibility needs to be included from the start, and not seen as an afterthought. They will be considering it!

Melanie Jones – Brooklyn, NY

Manhattan bridge in Brooklyn

As the resident non-technical person on the Simply Accessible team, I’m constantly bumping up against both how much I don’t know about accessibility and how much responsibility and impact I have as a content creator. GAAD 2016 coincides with the online launch of my newest book and a bunch of associated information products (worksheets, audio, etc). So for Global Accessibility Awareness Day 2016, I publicly pledge to make my site and products accessible to all kinds of users. I don’t yet know the ins and outs of how I’ll approach this, but I know I’m supported by a team of colleagues who can help me figure it out. I’ll need to make sure my WordPress site isn’t getting in anyone’s way, and I’ll need to provide transcripts for the audio files, as well as offer accessible versions of the PDF book file and worksheets (thank goodness Joanna just published an article about this). I’ll also need to learn more about e-book files (.epub and .mobi) and if barriers exist within them. I started the day embarrassed that my stuff wasn’t accessible, but I’m ending it feeling committed, galvanized, and inspired to do better.

Gavin Ogston – Ottawa, ON

a11yYOW logo

For GAAD this year, I’ll be heading over to a11yYOW, Accessibility Camp Ottawa. Ottawa has a great community of passionate web developers, but most of us are heads-down working on projects all year, so it’s a big deal to step away from our computers and reconnect with the community. A11yYOW was the first accessibility conference I ever attended, and I’ve been going back ever since to recharge and reconnect with the local accessibility community. The presentations offer a great mix of experiences, theory, and technical know-how, and there’s always something valuable to take away from the event. I can’t wait for GAAD—looking forward seeing what everyone is up to and what’s keeping them inspired and challenged in the field. I’ll report back after the event!

Derek Featherstone – Ottawa, ON

Abilities Centre Ottawa

I’ll also be spending Global Accessibility Awareness Day at a11yYOW, an entire afternoon with other accessibility speakers/panelists. I’ll be presenting, but what I really want to do at the event is chat with one of the other groups presenting, Abilities Centre Ottawa (ACO).

The ACO will be an inclusive, multi-purpose recreation facility designed with accessibility in mind. I’m planning to chat with them to see what opportunities exist for developers and designers to be involved. I want all of us web geeks to expand our horizons beyond an understanding of this little niche called Web Accessibility and start to think of broader inclusion initiatives. How does this facility integrate access and inclusion into everything they do? What can we learn from that for our work on the web? Can we find opportunities for people in our digital community to give back in a way that opens them up to learning new things about people with disabilities and see them as people, not “users”? I’ll let you know what I find out.

Scott Vinkle – Ottawa, ON

Ottawa, ON #CodePenOttawa

I took accessibility awareness to my CodePen Ottawa Slack channel. I asked my dev pals, “What’s one thing wish you knew more about when it comes to accessibility development and/or testing?”

Here are the responses I received:

  • “I’d love to see more videos of real users using websites, what that experience is like and how it could be better.”
  • “As a dev, I’d like to know more about the actual screen readers and how they behave. I spend my time building websites, and testing them using browsers and the built-in screen reader in my OS, but I’m limited when it comes to the real experience. I wish there was a place that would let us test some real assistive technology, and see how the users actually interact with our websites.”
  • “I don’t quite know how to word this, but I think one of the biggest challenges is not knowing it’s a problem to begin with. It’s not very clear what you need to learn. It’s sort of a cycle: without knowing what to learn, how can you learn more about it?”

Elle Waters – Louisville, KY

Person opening a large Braille book imprinting device

Located in a historic neighbourhood in Louisville, Kentucky, just 15 minutes from my house, is a venerable old building that houses the American Printing House for the Blind (APH). APH was established in the 1800s before the start of the Civil War. The oldest organization of its kind, the APH provided, and still provides, education and resource materials to help individuals of all ages, with the mission to help people achieve independence. They even have a tour of the printing house and a museum, with 7,000 visitors each year.

More recently, the APH has also become an active advocate of promoting awareness and to educate the blind. Beyond their educational outreaches to other organizations across the world and the incredible products that the they produce in their 280,000 square foot building, the APH is also doing some things lately that really excite the geek in me.

Cinema Saturday

On the second Saturday of each month during the summer, the APH hosts free showings of popular films with audio description. Afterwards, attendees are encouraged to participate in an ongoing discussion about Hollywood’s role and portrayal of blindness in films.

Product innovation

The APH is always looking for creative ways to solve problems or improve the efficiency of the tools, products, and services that they offer for blind individuals. They recently created a web form on their site to allow everyone the opportunity to pitch a new idea or a suggested improvement. Crowdsourcing innovation – fantastic!

How I’m celebrating GAAD 2016

In honour of SA’s homegrown awareness celebration of GAAD 2016, I will be interviewing Roberta Williams at the American Printing House for the Blind, here in Louisville, KY, and we’re going to discuss ways in which we can increase local awareness of all the work that this organization does to make the world a more accessible place.

We’ll keep travelling west throughout the day, checking in with our West Coast and Pacific team members as GAAD 2016 rolls along. Let us know how you’re celebrating Global Accessibility Day where you are. How are you generating awareness today?

The post Global Accessibility Awareness Day 2016, SA Edition (part 2!) appeared first on Simply Accessible.

Global Accessibility Awareness Day 2016, SA Edition (part 1!) Wed, 18 May 2016 22:22:42 +0000 This week, we'll share local happenings and resources so that you get inspired. Accessibility awareness is all around you, right underneath you, and right down the street.

The post Global Accessibility Awareness Day 2016, SA Edition (part 1!) appeared first on Simply Accessible.

The set-up

Our team is stationed all around Planet Earth. That’s right, we’re global! We’re also people who care deeply about accessibility and inclusion, and we put our money where our mouths are every damn day. We want to invite you along for the journey.

The vision

For this year’s Global Accessibility Awareness Day (GAAD), each one of us will be going to represent our hometowns and share with you how we’re celebrating GAAD. Think of us as your friendly, neighbourhood street reporters, drumming up some awareness wherever we live. Where’s that? Glad you asked! Our team: Eastern Canada, Western Canada, Seattle, Hawaii, England, Scotland, Australia, New York City, the Phillipines, Kentucky, and more! This week, we’ll share local happenings and resources so that you get inspired. Accessibility awareness is all around you, right underneath you, and right down the street. Check out some of our team’s plans for a homegrown GAAD 2016. Let’s start with our Wonder from Down Under, Julie Grundy, where the morning has already arrived!

Julie Grundy – Perth, Western Australia

Kangaroo crossing road sign in Perth, Australia

This year for Global Accessibility Awareness Day I’m doing something new: I’m hosting an A11y Bytes event in Perth. I belong to a great accessibility meetup group who get together for breakfast once a month, and we host an annual Accessibility Camp as a small, casual conference. But a lot of people can’t make it to a breakfast meetup or the camp, so I’ve been looking for ways to do some evening events. Sarah Pulis has been organizing the A11y Bytes events on GAAD for a few years now in Sydney and Melbourne, and I asked if Perth could join in. We’ve got local experts talking about document accessibility and demonstrating how people with vision impairments use screen reader software. We’ve also got developers from Seamless and Humaan showing how they’ve improved the accessibility of their carousel and modal plugins. I’m hoping people enjoy themselves and learn about how they could use their own skills to remove barriers in the way of everyone using the web!

Stuart Ashworth – Glasgow, Scotland

The Clyde Arc in Glasgow, Scotland at night

To generate a little hometown awareness, I posed a couple of questions to the web developer Slack groups I’m part of. A web designer friend had some interesting perspectives to share.


Why do you think websites aren’t often developed with an “accessible-first” mindset, in the same way there is a definite “mobile-first” mindset at the moment?

  • Some designers think of accessible design as something that will curb their creativity, and that accessibility equates to simple and boring designs.
  • The natural habit of designing for ourselves takes over to some extent. We all have mobile phones, so it’s easy to design for that user, the visibility of the use-case is big. We don’t all have disabilities that hinder our use of the web and so it’s harder to relate to what is required to make a website accessible.
  • It’s easy to justify “mobile-first” to bosses—you can tell them X% of users are using mobiles, so if we cater to them we can sell £Y more products. It’s much harder to quantify the benefits of accessible design and unfortunately that makes it harder to get signoff for budget/time to spend on it.

These are the kinds of objections we in the accessibility community face all the time. The good news is, we’re not phased by any of them and have incredible content that addresses each one. There’s Nic’s great post on thinking inclusively, which, if anything, calls for more creativity than less. And we’ve got Devon’s awesome keyboard accessibility for mobile post and tutorial, which shows us how to think accessibility-first and mobile-first at the same time! And we’ve got Elle’s impassioned call to action about making the business case for accessibility.

Jeff Smith – Amherst, NS

Downtown Amherst, Nova Scotia. A view of the Baptist Church and court house

My area (Cumberland County) in Nova Scotia has a lot of playgrounds for kids, but none of them are accessible. Most have climbing structures surrounded with sand or pea gravel that may prevent access for children and parents with disabilities.

Last fall, the Nova Scotia government announced it would be supporting the construction of a “natural accessible playground” in Springhill, Nova Scotia. Not only will this playground provide access to children with disabilities, but parents with disabilities will be able to play with their kids. I’m incredibly excited to see our provincial government recognizing the need to support physical access in the recreational space. This is more important than ever, given our culture’s shift toward less active lifestyles.

Additionally, the Nova Scotia government introduces the province’s first accessibility legislation this year. I’ve been in touch with my local Member of the Legislative Assembly (MLA), Terry Farrell to find out more about the physical and digital access initiatives he’ll be supporting during the crafting of the legislation. I’ll report back this week when I connect with him!

An illustrated globe with humans all floating around it, hands raised in unison

Stay tuned for more SA updates across the globe. We’re going surfing, we’re visiting historic printing houses, and we’re hanging out with the makers and talkers in our towns; you don’t want to miss what’s next! In honor of this year’s GAAD 2016 celebration, remember that from East to West, beach to hills, and everywhere in between… accessibility is right where you are.



The post Global Accessibility Awareness Day 2016, SA Edition (part 1!) appeared first on Simply Accessible.

Creating bulletproof headings Thu, 12 May 2016 15:46:34 +0000 With some changes to the W3C guidelines on the horizon, Julie walks us through some best practices for headings, one of the web's most humble-yet-powerful elements.

The post Creating bulletproof headings appeared first on Simply Accessible.

Headings are the unsung heroes of our websites. They do a lot of work to help us understand content at a glance, and we want to make sure that everyone can benefit from them. There’s been some confusion about the right way to use headings over the last few years. It’s partly about changes in the HTML5 specification, and partly about people not being sure why headings are even important to a website, apart from adding some visual flair. If you follow the three steps here, you’ll have bulletproof headings that can survive a trip from your HTML through the internet, delivered safely to any device with a browser.

Why you should care about headings

If you hardly ever read a whole web page from top to bottom, you’re not alone. User testing shows that a majority of us skim and scan, and we usually only read the entire page if we can’t find something pointing to the information we want.

People often judge a website by how quickly they can get what they need and leave. Headings are a great way to do just that. They’re visually larger than the rest of the content, so they stand out. They provide a description of what’s in each section, so people can skip ahead or stop when they find the section they need.

People who use screen readers also use headings to skim and scan the content on a long page. (My last post, Three common accessibility pitfalls for developers: information and relationships, takes you through an example of this.)

The most recent WebAim survey of screen reader users revealed some significant findings. According to the survey, 65% of participants rely heavily on headings instead of search features or link text to find their way through a long page. We see a similar result in our own user testing at Simply Accessible. Joanna Briggs, who oversees usability studies at SA said that “the vast majority of screen reader users in our usability studies use headings to navigate content-heavy web pages.”

Headings also help people create a mental outline of the content on the page. We know the biggest heading is probably the page title, and smaller headings are for chunks of content that are related to each other. For example, Wikipedia uses the heading elements to create a short table of contents for each article. See how the sub-headings in this Wikipedia article create an outline of the content you can expect to find:

A screen capture of a Wikipedia page on wombats, clearly showing a table of contents composed of heading elements

Headings can also create a useful Skip Navigation menu. That’s what we’ve done on our site. The first item on every page is a menu which takes the headings and turns them into links to that section.

A screen capture of the Simply Accessible home page showing a Skip Navigation menu with all of the page's sections listed

So how can we make sure we’re giving our users the most useful headings?

Breaking heading news

In 2014, the HTML5 specification recommended a new method of creating a document outline based on an idea originally suggested in a 2008 working draft. The concept was that the structure of a page could be created by container elements like section, article and aside combined with the heading elements. That way, you could start the heading levels with H1 in each new section and the document outline would also be correct.

Heaps of people were really happy about this change. More and more sites are syndicating content: blogs might be viewed in a feed reader, news articles might be viewed in Facebook, or videos might be taken from YouTube and embedded in personal sites. And people who care about these things still want the heading levels on a web page to be correct, even if sections are taken from one site and viewed in another. A lot of articles were written about how to use the new HTML5 document outline method, and developers started including it in their sites and templates.

There’s just one catch, though.

In all the time since work began on this document outline almost a decade ago, and in the two years since it was fully specified, not one browser has implemented it.

They all stuck to the HTML4 method. Of course, we don’t expect lumbering giants like Internet Explorer to adopt new features right away, but not even the small, nimble, or experimental browsers wanted to introduce HTML5 document outlines. Where did this lead, you ask?

As you can imagine, it created some confusion for people trying to learn HTML5 and those who make recommendations about code standards for their workplace or clients. Developers had been told to use the HTML5 method, but when they tested their pages, the outlines weren’t what they expected. People who rely on screen reader software were also confused—a lot of sites started using H1 for most headings instead of the full H1 to H6 rankings. Not all of them, just some of them! What a mess. It’s all been a bit of a muddle.

Luckily, this will be resolved soon. The W3C editors are revising the specification to better match the real world, which always takes time if you want to do the job right. In the meanwhile, they’ve added a warning to the most recent version of the HTML5 specification that the document outline method hasn’t been implemented. But the need for an alternative document outline method hasn’t gone away—people still pull content into different sites like Facebook and that’s not going to stop anytime soon. So the W3C editors are also looking at other options, including a possible <h> element which has its level calculated by its position in the page.

You might be wondering how you’re going to organize your headings after all this.

It turns out, what works in the real world is the method accessibility advocates have recommended all along. And since the W3C is pretty good at keeping things backwards-compatible, you’ll be able to keep using this method until all the quirks have been worked out in any new approaches that come along. Let’s take a look at it now.

Creating stellar headlines

To create a useful page structure, it’s critical to make sure the headings give all users information about what type of content is on the page and how it’s organized. There are three main steps to do this. I’ll take you through the process with a little single-page fan site for my favourite marsupial, the wombat. I actually want it to be more interesting than the Wikipedia page on wombats. And if someone has Googled for “photos of famous wombats” and discovered my site, I want them to be able to easily skip the life-cycle information and get straight to the photos.

Step 1: Use real heading elements

First, we need to make sure we’re actually using heading elements in our HTML to mark up the things that look like headings to our sighted users.

If this is our CSS…

.page-title {
  font-size: 2.4em;
  font-weight: bold;
  color: #000000;}

Then this div with a class of heading…

<div class="heading1">Wombats: the best marsupial</div>

and this actual heading…

<h1 class="page-title">Wombats: the best marsupial</h1>

…will look the same to me. I can tell that the first one is a heading, but the browser doesn’t know this, so it won’t let the screen reader software know about them. That means the heading shortcuts in JAWS, VoiceOver, or other screen readers won’t work, and people will just hear a “No headings on this page” announcement. Using the appropriate heading element will fix this for you.

Step 2: Create a nested structure to organize the content

Next, we need to make sure headings are in an order that makes sense to people who rely on them to understand the structure of the page.

We’ll use the top level heading, H1, for our page title, and H2 for our major sections. Then we’ve got everything from H3 to H6 if we need subsections or really specific chunks of information. You can still use the HTML5 sectioning elements for your own purposes, just don’t rely on them to give your readers any hint of how your page is structured.

Try not to skip any levels in the structure. If one of your visitors using a screen reader hears “Heading level 2, Wombat habitat; Heading level 5, Buy a photo” it could easily sound like they’ve missed a huge chunk of the content even if they’ve navigated correctly.

So, my wombat fan page has a structure like this, with only one H1 on the page, H2 used for the main section headings and H3 for sub-headings:

  <h1>Wombats: the best marsupial</h1>
    <h2>Habits and habitats</h2>
    <h3>Where to find them</h3>
    <h3>What they eat</h3>
    <h3>Lifecycle of a wombat</h3>
    <h4>Early life</h4>
    <h2>Famous wombats</h2>
    <h2>Photos of wombats</h2>
      <h3>Wombats in the wild</h3>
      <h3>Wombat photos from zoos and wildlife parks</h3>
      <h3>Photos of famous wombats</h3>

Step 3: Give your users useful content

Finally, headings need to be descriptive and useful. There’s no point making a lovely outline structure for our page if we’re going to use generic headings like “Learn more” or “Visit.” What are we going to learn about, and who are we being invited to visit? Let people see at a glance what you’re offering, instead of making them read every word.

To make scanning headings as easy as possible, you should make your heading content both specific and unique. Describe what people can expect to find in that section, and don’t repeat the same heading text when the content that follows it is different.

I think this means the Photos section of my website could do with some changes to the text. Let’s try again:

    <h2>Photos of wombats</h2>
      <h3>In the wild</h3>
      <h3>At zoos and wildlife parks</h3>
      <h3>Famous wombats</h3>

They’re simpler and catchier, but still let everyone know what kind of photos to expect. Use relevant keywords and skip any repetitive phrases, and your headings will be easier to scan.

It’s not easy to get clear and accurate guidance about the powerful-but-humble heading—I hope this has clarified the path to creating rock solid signposts to content people need.

The post Creating bulletproof headings appeared first on Simply Accessible.

Real users on Adobe PDFs Thu, 05 May 2016 15:00:46 +0000 This week, Joanna mines one of our most valuable resources—Simply Accessible's usability panel—real users who test what we make to ensure our sites and apps are truly accessible. We asked them what barriers they face when accessing PDF documents on the web. Here's what they had to say.

The post Real users on Adobe PDFs appeared first on Simply Accessible.

PDFs (Portable Document Format) present documents independent of software, hardware, or operating systems. Developed by Adobe in 1991, PDFs were proprietary until 2001, when they were released as an open standard. Now, they’re a pretty ubiquitous way to share branded or design-heavy documents across operating systems, the web, mobile, or through email.

Ah, but are they accessible? In their usual form, not really.

PDFs can have an excellent document structure, which makes them navigable by everyone including folks using screen readers. But, all too often good document structure is exactly what’s missing. Long documents don’t have headings to break up the content. Content gets read out of sequence. Images don’t have a text alternative, or the whole document is one giant scanned image. The list goes on.

The accessibility issues that pop up with PDFs often mirror those found in poorly structured HTML documents.

What actual users have to say

Usability testing with real users is a part of every Simply Accessible project. We’ve got a panel of folks from all over the world who use various assistive technologies and modifications to work with the web. These participants span a huge range of ages, professions, and disabilities including vision impairments, dexterity or mobility challenges, hearing challenges, or cognitive disabilities.

User testing is a huge part of what we do—who better to let us know how sites and apps are working than the end users we’re trying to serve?

We asked our fearless panel to weigh in on PDFs from their vantage point, and here’s what they had to say.

Good structure goes a long way

First off, we heard about how important structure is:

“I like when PDF files are properly tagged for accessibility, and when the different section titles are properly marked up as headings so that I can get to the information that I want quickly.”
– Male, 19-34 years old, JAWS user

What happens when a PDF isn’t tagged to have a good structure?

“I can open it, but my screen reader doesn’t always read it. JAWS often says ‘document empty’.”
– Female, 35-54 years old, JAWS user

She’s talking about a document that’s probably a scanned image.  So, there’s something visible but nothing that she can use.

“What do I do when I run across a PDF? I swear creatively! Though I used to be able to access PDFs easily, as JAWS and Windows evolved, they don’t seem to like PDFs anymore. After the swearing, I usually get somebody else to access the thing on their computer.”
– Female, 35-54 years old, JAWS user

If there’s a problem, many people will blame their own software or hardware, or themselves. But when she describes something that stops working—the problem is with individual documents.

“Though PDFs are usually usable, they’re not as screen reader-friendly as most websites or Word documents. I try using my screen reader on the PDF, and if that doesn’t work, I usually give up. If it’s extremely important for me to access the information, I use the OCR (optical character recognition) feature to try extracting the content.”
– Female, 35-54 years old, ZoomText reader and magnifier user

When she knows that she needs the information in a PDF, you can see how far she’ll go to get at that important information—using OCR software. Other people we talked to also use OCR to access a PDF. Some even print it out and then scan it with Open Book (software that converts printed documents or graphic-based text into electronic text). Others use OCR in newer versions of JAWS. While this technology can be just amazing, it can sometimes also have problems with multi-column documents.

Plus, doesn’t this seem like an excessive amount of work to access something that should be simple?

Consider high contrast settings

Like all barriers to accessibility, PDFs don’t just impact people who use screen readers.

“PDFs are frustrating. The document colour doesn’t come through inverted with an ‘inverted colour high contrast’ setting on the Windows OS. Any time I receive a confirmation for a reservation as an attachment in a PDF format, it’s unreadable to me. It usually displays with a white background and black text, but the brightness of the white background takes over and masks the black text. Any sort of flyer or document that’s posted in an email or on a website as a PDF isn’t visible with an inverted colour scheme on a Windows operating system. This is very frustrating as an increasing number of important documents are sent as PDFs.”
– Female, 35-54 years old, Windows High Contrast user

High Contrast is a built-in accessibility setting on Windows. The colour scheme uses a black background, reverses the text, and removes CSS backgrounds which makes everything easier to read. It’s easy to turn on with just Left Shift+Left Alt+Print Screen. If you’re not using Windows, here’s what it looks like:

Simply Accessible’s home page in Internet Explorer with Windows High Contrast. The page background is black with yellow text

It turns out the default settings of Adobe Reader ignore a user’s High Contrast settings on Windows. And, the options to adjust it are buried deep in the many available preferences. When you include a PDF on your site, it may create a real barrier for people who use high contrast with default Acrobat settings.

If you do use High Contrast on Windows and are trying to access a PDF, we’ve put together instructions on how to change the defaults in Adobe Reader to work better with high contrast.

Mobile considerations

As a format on mobile devices, PDFs are less than ideal.  From a person with low vision:

“I can’t easily read a PDF on a mobile. I would need to use a hand-held magnifier over the mobile screen.”
– Female, 55+, ZoomText user

For a VoiceOver user, the KNFB Reader makes access to PDF documents easier on mobile devices.

“I use iBooks with the iPhone as well as the KNFB Reader to read PDF documents, especially ones with images.”
– Male, 19-34 years old, VoiceOver user

But, ideally, the PDF should have an accessible structure and not need the OCR power of the KNFB Reader.

Our recommendations

This is a lot of information to digest, and we don’t want to leave you struggling with what to do next. Here are some basic starting points to consider.

  1. Don’t use the PDF format if you can help it. If you can create a web page, do that instead. A properly formatted web page—including good HTML heading structure and text alternatives for images—is inherently more accessible to a broader range of people.
  2. If it’s intended for print, think about providing multiple print formats. When you have a PDF document that’s meant to be used as a printed document, offer a large print format for people with low vision.
  3. Make it clear that a link goes to a PDF. Use a foreground icon with an alt attribute to let people know the file is a PDF ahead of time. Also, let people know what size the document is in advance.
    <a href=”AnnualReport2016.pdf”>Our 2016 Annual Report
    <img src=”pdf-icon.png” alt=”PDF”> 2 MB</a>
  4. All of the usual web accessibility principles and best practices apply for a PDF document. You’ll need proper colour contrast, text alternatives for images and any embedded media, and good document structure like headings. This is where making a well-structured HTML document might require less work.

What have you come across in your practice to help make PDFs more easily accessible? Share your strategies in the comments below.

The post Real users on Adobe PDFs appeared first on Simply Accessible.

Using the Windows High Contrast colour scheme with Adobe Acrobat Reader Thu, 05 May 2016 15:00:21 +0000 High contrast mode is great for readability, but if you're trying to read a PDF, you'll need to do some tweaking in Adobe Reader. We'll walk you through it.

The post Using the Windows High Contrast colour scheme with Adobe Acrobat Reader appeared first on Simply Accessible.

Microsoft Windows’ High Contrast colour scheme is a built-in accessibility setting that helps improve readability. It uses a black background, reverses the text colour, and removes CSS backgrounds which makes everything easier to read. It’s easy to turn on with just Left Shift+Left Alt+Print Screen.

Using a high contrast setting is great for those with low vision. It reduces glare and works to eliminate white backgrounds as much as possible. Foreground images are still visible (but can be a problem if they have white backgrounds), and the Windows setting removes background images. Reducing distracting images on the page can make it easier to focus on reading. And, beyond its benefits for folks with reading disabilities, some people just prefer the black background.

High Contrast in Windows makes everything, including web browsers, appear in high contrast with one big exception: PDFs. You have to tweak your Adobe Reader settings separately to view PDFs with high contrast.

Here’s how to do it:

  1. If you open the Adobe Acrobat Reader program without opening a file, the program window should respect your existing high contrast colour scheme.
  2. Then, go to the main menu and choose Edit > Preferences.
    In Acrobat Reader, Preferences is the last option under the Edit menu. It can also be accessed with Control + K.
  3. In the Preferences, there’s a sidebar with an Accessibility option.
    In the Preferences dialog, Accessibility is one of the options under Categories which exposes all of the Accessibility settings for Adobe Reade
  4. The first option in the panel on the right is Document Colours Options. If you check “Replace Document Colours,” there are a bunch of choices including “Use Windows Colour Scheme.”
    A close-up image of the colour options available to you in the Accessibility menu
  5. Select “Use Windows Colour Scheme,” any of the high contrast combination options in the drop-down menu, or customize your own page background and text colours.
  6. Make sure “Only change the colour of black text or line art” is not checked.
  7. Check the option for “Change the colour of line art as well as text.” This will deal with any other text and background colours that are in PDFs.

The post Using the Windows High Contrast colour scheme with Adobe Acrobat Reader appeared first on Simply Accessible.

Ramps gone wrong: the problem of putting accessibility guidelines ahead of user experience Wed, 27 Apr 2016 04:00:28 +0000 Mark shares a cringe-worthy but illuminating example of how compliance and guidelines can get in the way of good user experience.

The post Ramps gone wrong: the problem of putting accessibility guidelines ahead of user experience appeared first on Simply Accessible.

The Web Content Accessibility (WCAG) Guidelines have been good to me. They’ve given me a career I’m proud of. They’ve indirectly put food on my table and a roof over my family’s head. More importantly, they’ve made a huge difference to the online experience of millions of people the world over. Many of these folks may be completely unaware of the guidelines themselves, but they’re very aware of the barriers they face when accessing content online.

But does adherence to success criteria really produce a better experience for users with disabilities? The WCAG guidelines certainly address many of the major accessibility barriers faced by disabled users, but does this equate to better UX?

The tale of Katie Lally

Stepping away from the WCAG guidelines for a moment, as an accessibility consultant living and working in Scotland, I am alternately tickled and horrified by the baffling tale of Katie Lally’s wheelchair ramp—a story that brings the guidelines versus user experience problem into stark relief.

Katie is a young girl from West Dumbartonshire, Scotland who uses a wheelchair. Her mother campaigned to the local council for assistance overcoming the nine steps from the street to their front door. No problem, said the council.

The resulting wheelchair ramp made national headlines and quickly went viral. Why? The sprawling ten-level behemoth obliterated the Lally’s entire front garden and attracted skateboarding teenagers from miles around.

A ramp taking up the whole front yard, winding back and forth over ten switch-backs or levels.

Skateboarders were thrilled with the result, but the Lallys (and the mail carrier) sure weren’t.

At some point in the process, the council stopped thinking about Katie Lally’s needs and started to prioritize their internal guidelines related to building wheelchair ramps. A good user experience was sacrificed at the altar of maximum allowable gradient.

This situation isn’t limited to just offline accessibility. The same pitfalls can and do happen in the online world, as we saw in Jeff’s post last week about ARIA tabs.

Meeting guidelines alone won’t always make your product or service a good experience for disabled users. Often, organizations make something technically accessible without considering the needs of the actual people using it.

Putting people first

It’s easy to see why these issues happen. Pressure to ensure that services are accessible usually leads to organizations applying accessibility features on top of existing content and processes. There isn’t the time, budget, or in some cases appetite, to redesign services from the ground up with disabled users in mind. Nic’s post about “managing accessibility” gets into the meat of that issue.

The good news is, there’s a simple way to prioritize the people who need us ahead of the things we build. Usability testing with real users can quickly provide key insights into how people actually interact with a product or service. It’s a brilliantly efficient reminder of the real purpose behind our work.

Users don’t think in terms of guidelines. They have a task in mind that they want to complete, and their experience is defined by whether they can complete it or not.

We regularly encounter folks who can’t complete tasks online even though the interaction met technical guidelines—and there’s often no other way to identify these problems other than user testing. Testing helps you understand what people really want and why, and how someone actually engages with your site. It helps keep the user in the forefront of the team’s mind in a way that simply applying the WCAG guidelines doesn’t.

Using the experience of real people to complement the WCAG guidelines is the best way to avoid building your very own online wheelchair skateboard park. Guidelines are only part of the accessibility picture—front and centre of your focus should be your very own Katie Lally.

How do you balance the need for compliance with the need for good user experience? What helps you keep your end users top of mind?

The post Ramps gone wrong: the problem of putting accessibility guidelines ahead of user experience appeared first on Simply Accessible.

]]> 1
ARIA thunder: why we published a controversial post (and why we’ll probably do it again) Fri, 22 Apr 2016 15:48:53 +0000 Our post last week about the pitfalls of ARIA tabs pushed some buttons in the accessibility community. This week, Derek responds to the reactions and shares why we felt it was important to publish something that made our readers uncomfortable.

The post ARIA thunder: why we published a controversial post (and why we’ll probably do it again) appeared first on Simply Accessible.


We suspected when we wrote the article we wrote last week that it might not be too popular. That it might be surprising. That some people might have very mixed reactions to it. The reactions we got on Twitter certainly seem to confirm our suspicions.

Some people were frustrated:

Some people were confused:

Some people came out in full support of the viewpoint that we believe in and published:

We kinda knew debate would happen, and we were okay with it. Why?

Because we have to question current practice. We have to question the guidance that we’re given. We have to question the direction in which we’re going—and whether it’s leading us to the right place.

Most of us in the accessibility field base our solutions on experience with assistive technologies (usually screen readers, if we’re all being honest), or we base them on working directly with people with disabilities. But how often are new solutions really and truly tested with people with disabilities? Not nearly as often as they should be.

I get why the article hit a sore spot with a LOT of people. It calls into question years of work on ARIA. It calls into question the trust that web pros place in accessibility people to get it right and provide the guidance that non-accessibility specialists need. It calls into question the things that you thought you knew. And all of that can be quite painful.

Best practice evolves. What is best practice today may be completely shunned in six month’s time. (Look at icon fonts.)

Accessibility is no different.

We shouldn’t be surprised when the accessible implementation we find today isn’t the pinnacle of accessibility tomorrow. We should find out whether or not a solution actually works well for people with disabilities in usability testing. We should question whether that complex structure is really the best solution—and whether ARIA is the best tool for the problem we’re trying to solve.

Because accessibility is often ignored, we sometimes think “anything is better than nothing” and that technically accessible solutions are “good enough.” But good enough often isn’t.

Simply Accessible doesn’t take on projects where usability testing is excluded from the work that needs to be done. We want to go beyond just meeting technical requirements. From where we sit, if it’s technically perfect but unusable by people with disabilities, it doesn’t matter that we followed all the rules.

Accessibility isn’t about specs. It’s about people. Our job is about making sure people can use things we make.

And so, we presented scenarios from the usability testing that we’ve done—because it’s a treasure trove of insight and goodness. I know that not everyone can do user testing. So that’s part of why we do it. And why we feel compelled to share our findings with you, our community.

The post ARIA thunder: why we published a controversial post (and why we’ll probably do it again) appeared first on Simply Accessible.

]]> 5
Danger! ARIA tabs Thu, 14 Apr 2016 19:00:32 +0000 ARIA is a great way to make things technically accessible, sometimes without requiring markup changes. But it can be tricky, even if you're using it in a technically correct way. In this post, Jeff breaks down an ARIA tabs interaction to see how ARIA can impact users with disabilities—and how to make tabs truly accessible.

The post Danger! ARIA tabs appeared first on Simply Accessible.

At Simply Accessible, we believe strongly in including people with disabilities in our usability studies. We test both code and design prototypes as well as web pages in production, and it’s incredibly important for us to see how our users interact with our clients’ sites. It’s difficult to predict how different types of users will experience a given interaction. The results of usability testing can sometimes be quite surprising.

ARIA tabs are one of those surprises.

ARIA is a great way to make things technically accessible, sometimes without requiring markup changes. But ARIA is tricky, even if you’re using it in a technically correct way. At some point, the theory breaks down in practice, and users get stuck in the middle of an interaction. In this post, we’ll build an interaction from the ground up to understand why this can be a challenge for people. Sometimes, a widget or interaction that’s technically accessible…isn’t.

A brief introduction to ARIA tabs

Tabbed interfaces are one of the more common interactions we see on many websites. Tabs and tab panels serve as an excellent way of grouping content together and presenting it in digestible chunks for our users.

But, when we’re working with ARIA tabs, sometimes even textbook-perfect tabbed content can cause serious challenges for some users. First, let’s build some tabs, starting with good old HTML.

The basic markup for tabs starts out simple and clean. This provides a good semantic base:

<div id="tabs">
    <ul class="tabsList">
        <li><a href="#ipa" id="tab-ipa">India Pale Ale (IPA)</a></li>
        <li><a href="#gueuze" id="tab-gueuze">Gueuze</a></li>
        <li><a href="#imperial-stout" id="tab-imperial-stout">Imperial Stout</a></li>
    <div class="tabPanel">
        <h2 id="ipa">India Pale Ale (IPA)</h2>
    <div class="tabPanel">
        <h2 id="gueuze">Gueuze</h2>
    <div class="tabPanel">
        <h2 id="imperial-stout">Imperial Stout</h2>

Next, with progressive enhancement, we’ll layer on some extra attributes and ARIA roles, and use JavaScript to provide:

  • a programmatic connection between our list of tabs and the tab panels; and
  • a programmatic indication of the state of each tab panel—hidden vs. visible.

Ideally, both of these additions will help users of assistive technology successfully interact with our tabs:

<div id="tabs">
    <ul class="tabsList" role="tablist">
        <li role="presentation" class="current"><a href="#ipa" id="tab-ipa" role="tab" aria-selected="true" tabindex="0">India Pale Ale (IPA)</a></li>
        <li role="presentation"><a href="#gueuze" id="tab-gueuze" role="tab" aria-selected="false" tabindex="-1">Gueuze</a></li>
        <li role="presentation"><a href="#imperial-stout" id="tab-imperial-stout" role="tab" aria-selected="false" tabindex="-1">Imperial Stout</a></li>
    <div class="tabPanel" role="tabpanel" aria-hidden="false" aria-labelledby="tab-ipa" style="display: block;">
        <h2 id="ipa">India Pale Ale (IPA)</h2>
    <div class="tabPanel" role="tabpanel" aria-hidden="true" aria-labelledby="tab-gueuze" style="display: none;">
        <h2 id="gueuze">Gueuze</h2>
    <div class="tabPanel" role="tabpanel" aria-hidden="true" aria-labelledby="tab-imperial-stout" style="display: none;">
        <h2 id="imperial-stout">Imperial Stout</h2>

ARIA tabs consist of a role="tablist" element, which has some some role="tab" elements. These tabs are then linked to role="tabpanel" elements that contain the corresponding content for each tab. Our JavaScript handles the visual toggling of tabpanel elements via CSS as well as programmatically with aria-hidden="true" when a user interacts with the tabs.

Following guidance from the WAI-ARIA 1.0 Authoring Practices for the Tab Panel Widget, we’ll also supply keyboard behaviour for our ARIA tabs. These interactions have some notable differences from what we would usually expect from a list of links:

  • Only the current, active tab is in the tab order of the page. We’ll remove inactive tabs from the tab order by applying tabindex="-1".
  • When focus is within the list of tabs, using the arrow keys on the keyboard, a user is able to navigate and activate the other tabs in the list.

See the full example Standard ARIA tabs by Jeff Smith (@jeffsmith) on CodePen.

The programmatic thinking behind this set of tabs is rock solid. This implementation should provide all our users with a great experience, right?

Well, maybe not…

What real users experience

We’ve tested a few different ARIA tab implementations in our usability sessions with real users. We were incredibly surprised with what participants experienced.

Some of the non-visual users in our studies used the links list functionality in their screen reader software. When they did, the links with role="tab" within the role="tablist" element didn’t show up in the list. These elements have moved to a list of ARIA elements—a relatively new piece of functionality in screen readers, and one that some folks weren’t familiar with. So, these users weren’t able to find any of the content contained in the inactive tabs.

Also, many sighted keyboard users were frustrated when the ability to tab to each individual tab was removed through the use of tabindex="-1". People often weren’t aware of the arrow key shortcuts that replace the tabbing interaction they’d normally use to move between links/interactive elements. This includes people who use magnification tools with their screen reader (like ZoomText).

The arrow key shortcuts also impact screen reader users. These users have to use a pass through modifier key (ie. the alt key) to activate each tab, which bypasses the native screen reader arrow key behaviour (reading line by line, word by word, or character by character) and instead passes the keystroke directly through to the page.

Even though they could see that the tabs existed, some people weren’t able to figure out they needed to use the arrow keys to toggle the inactive tabs, so they couldn’t access that content.

Quite often there is critical information or functionality contained within tabs. With so many groups of users unable to navigate the interaction, these tabs now represent  a pretty significant barrier for task completion.

So what can we do about it?

We’re in luck! A few small changes to our initial example will make a huge difference for our users.

To begin, let’s remove the role="tablist", role="tab", and role="tabpanel" attributes from our script. This will prevent screen readers from removing these elements from the standard element lists that many people rely upon.

Next, let’s remove tabindex="-1" from the links that serve as tabs to improve the experience for keyboard users by restoring the tabbing behaviour they’re used to with links.

<div id="tabs">
    <ul class="tabsList">
        <li class="current"><a href="#ipa" id="tab-ipa" aria-selected="true">India Pale Ale (IPA)</a></li>
        <li><a href="#gueuze" id="tab-gueuze" aria-selected="false">Gueuze</a></li>
        <li><a href="#imperial-stout" id="tab-imperial-stout" aria-selected="false">Imperial Stout</a></li>
    <div class="tabPanel" aria-hidden="false" aria-labelledby="tab-ipa" style="display: block;">
        <h2 id="ipa">India Pale Ale (IPA)</h2>
    <div class="tabPanel" aria-hidden="true" aria-labelledby="tab-gueuze" style="display: none;">
        <h2 id="gueuze">Gueuze</h2>
    <div class="tabPanel" aria-hidden="true" aria-labelledby="tab-imperial-stout" style="display: none;">
        <h2 id="imperial-stout">Imperial Stout</h2>

The final piece of the puzzle is focus management.

Since we’re removing tabindex="-1" from inactive tabs, we don’t want users to be forced to navigate through all the inactive tabs just to get to the newly revealed content. Instead, when a user activates a tab, we should place the focus on the first heading contained within the revealed tab’s content using JavaScript.

// Where var tabpanel is our revealed tab content
tabPanel.children("h2").attr("tabindex", -1).focus();

So, wait. We’ve removed ARIA roles from our code, and we’ve actually made these tabs more useful for our users? In this case, we have indeed. People navigating the tabs with a screen reader will no longer hear that they’re navigating tabs. But, now they’ll be able to locate and access the content that they expect, and need, to find.

See the full example Standard tabs without ARIA roles by Jeff Smith (@jeffsmith) on CodePen.

The best approach to fixing most interaction problems is to start out by solving as much as you can via plain old HTML and JavaScript. If there are gaps remaining, ARIA can provide a great help in filling those gaps, but it’s incredibly important to test these solutions with real people.

What other accessibility techniques have you come across where the technical solution doesn’t always yield the best user experience? How did you resolve the issue, and maybe more importantly, what best practices did you discover to help us all improve? Share in the comments below!

The post Danger! ARIA tabs appeared first on Simply Accessible.

]]> 25
First-hand knowledge: what my injury revealed about web accessibility Thu, 07 Apr 2016 21:43:49 +0000 Nic shares how the experience of injuring his hand brings up a lot that relates to our work in web accessibility. From learning and working with assistive technology to the emotional impact of dealing with an impairment, his experience shines a light on the human side of our work.

The post First-hand knowledge: what my injury revealed about web accessibility appeared first on Simply Accessible.

I broke my scaphoid bone a couple weeks ago. It’s having a serious impact in my ability to do everyday things. It’s temporary, true, but quite disabling. I’m finding ways to do things, and I’m adapting—but it’s not easy. Let me tell you about it.

The diagnosis

Photo of Nic's left hand in a cast, his thumb completely immobilized.The scaphoid bone is one of the carpal bones in the wrist. It lives at the base of the thumb and is typically injured when someone falls with their hands outstretched. Apparently, it’s the most common carpal bone fracture. It can also be quite difficult to heal. Because I’m not supposed to rotate my hand very much at all, the doctor put me in a cast that immobilizes my wrist and my thumb. I’ll be in a cast a minimum of three months, and if I’m lucky, I’ll avoid having a screw put in my bone to hold it in place.

The impact

This tiny bone is affecting all areas of my life. Showering is a logistical puzzle. Cooking is significantly slower. Getting dressed is tricky, and gaming on my Xbox is just not possible. There’s also the fact that I’m a wheelchair user. Pushing a manual wheelchair with one-and-a-half hands is neither effective nor graceful! I’m frustrated and I feel helpless. I can’t type my usual eighty words per minute. In fact, I can’t use my left hand at all to type. Considering I make a living using a computer all day, every day, this has really slowed me down.

The great thing about humans is, we adapt. Living with this impairment, even though temporary, is an ongoing adaptation for me. I’m learning new techniques and new-to-me tools. It can be frustrating and learning takes time. Nonetheless, I’m adjusting.

Image of two Xbox controllers, one for two-handed use, one for single-handed use.For example, I really wanted to be able to continue playing Skyrim during the twelve weeks I’ll be in this cast. I looked for, and found, a one handed Xbox controller. It’s very clever. But it costs more than $300, and it wouldn’t be delivered for six weeks. So, timing-wise and cost-wise, it’s not going to work for me. This may seem silly, but the inability to game is having an impact.

Impairments and disability are sometimes most deeply felt in the so-called “little silly things.”

A lot of the impact of my injury, though, is neither silly nor little. Relying on one hand to use the computer, especially when you’re so comfortable using both hands, is no joke for a web professional. I’m relieved I didn’t injure my dominant hand. At least I can still use a mouse or trackpad without having to adapt or relearn that.

But, reaching all the keys on the keyboard isn’t possible the same way I’m used to. One of the problems one-handed typing presents is being unable to use modifier keys such as the command key, the option key, the control key, or the shift key. You normally use two hands for those. Sometimes, you can use one hand if you have a really wide reach between fingers—I occasionally do this reflexively with my casted hand and wow. It hurts! (Bad for healing, too.)

Touch typing is also impossible. I’m back to hunting and pecking the keys with my right hand. This slows things down and increases the risk of typos. I have no doubt that eventually I’d adapt and develop a one-handed typing technique that would work flawlessly. But this kind of re-learning takes time.

To ease that, I’ve turned to two main things.

The solutions

One of the first accessibility features I enabled was sticky keys. I knew about this feature but had never really used it myself. It’s available in both Windows and OS X, and it allows you to type modifier keys and make them “stick.” So you can type the shift key and then the letter R, for example, and the letter will be capitalized. Using sticky keys had a bit of a learning curve, but it wasn’t that bad. It’s been a godsend.

The other thing I started using is Dragon NaturallySpeaking. Dragon is a speech to text software: I talk and it types. It also allows command and control, so I can control all functions of the operating system and applications. I can start software, navigate through the menus, surf the web, all by voice. Catch is, there’s a steep learning curve to Dragon. For me the dictation was easier for having used Siri on my iPhone before, but it requires another way of thinking about text creation than I’m used to. Incidentally, the first draft of this post was 95% written using Dragon.

I’m developing a hybrid technique for myself: a mixture of one-handed typing, sticky keys, and Dragon NaturallySpeaking. Perhaps by the time I’m out of this cast, I’ll be a pro.

The insights

Beyond the physical adjustments, there have been emotional ones as well.

This process of re-adaptation is interesting to me. I know this is temporary. But, it’ll last long enough that it has an impact. I’m also uncertain about how well I will heal. Will there be residual impairment? There’s simply no way to know at this point. I feel worry, and also grief. It doesn’t matter that I went through a similar process before, when I moved to full-time wheelchair use.

Previous experience with adapting to a new situation or impairment doesn’t immunize you against the emotions that come up if you have to do it again.

At Simply Accessible, we work to make the web more accessible to people with disabilities. This includes people who, like me, acquire a temporary condition. My injury serves as a reminder that there are different implications to temporary impairments than to permanent ones.

When you’ve been living with a condition for years, you’ve learned to adapt. You’ve developed tools and techniques—you’ve mastered your workarounds. But, with a temporary or new condition, you’re still in the process of finding your way. You fumble and fail. And, you can be dealing with an emotional struggle that shouldn’t be underestimated. Once again, accessibility isn’t about a condition, or a disability, but a person trying to work it all out.

What are your experiences adjusting to temporary impairments? If you’re a web accessibility professional, did these adaptations give you insights about how you do your work? Share your experiences in the comments below.

The post First-hand knowledge: what my injury revealed about web accessibility appeared first on Simply Accessible.

Keyboard support for mobile: the tutorial Thu, 31 Mar 2016 20:08:57 +0000 In a tasty follow-up to her article about keyboard accessibility for mobile devices, Devon walks us through a pizza-themed tutorial, bringing keyboard support life in the most delicious way.

The post Keyboard support for mobile: the tutorial appeared first on Simply Accessible.

Back in the oven

picjumbo.com_20140314-DSC_0138Previously in Supporting the keyboard for mobile, we talked about how considering keyboard-only interactions in your mobile web thinking is a great way to guide design and development choices that are intuitive, inclusive, and easy to iterate upon. Breaking down interactions into microtasks helps you see all the nooks and crannies of your design and implementation, and makes a huge impact on a wide variety of users accessing your content under a myriad of circumstances. With some practice, you can integrate this way of thinking into your existing mobile web design workflow.

Learning new techniques for UX and code design is often easier said than done, so let’s walk through an example together. To demonstrate, we’re going to build part of a pizza order form. Forms are sometimes a pain on the best of days and devices—and they can be particularly challenging on mobile, especially when we’re in a hurry. Or hungry.

What’ll it be today?

an array of pizzas in cardboard boxes and soda cans on the floor with people sitting cross-legged around the feastThe scenario: Your local pizzeria’s favorite customer, Toni Pizza, is at a party, and wants to order some pizza on her phone. Your challenge: let her order with minimal fuss, with an assistive technology (or one thumb or with a low battery or in bad light or with attention that’s scattered by background noise—it’s a party after all).

We’ll focus on the pizza part of the ordering process, where users get to design the pizza of their dreams.

Ingredients list

Several Post-It notes illustrating the brainstorming process behind the order form including sizes, amounts, toppings, and custom pizzas.Every form is designed to get information from users to help them meet their goals, so every form is basically a series of questions.

Our first step is to break down the larger task into the smallest pieces, the smallest questions, we can. But, let’s not get bogged down in order or process yet (putting the sauce before the crust, as it were). Simply jot down the list of questions we need to ask our users.

You might do this as a bullet list, a set of Post-It notes, or whatever tools you prefer for brainstorming or note-taking:

  • How many pizzas does the customer need?
  • Does she want a predesigned pizza from the menu, or to create a custom one?
  • What size pizza(s)?
  • Is cheese optional?
  • What toppings?
  • Should the toppings be on a specific side, so the party host who likes olives and the guest who likes anchovies can continue to speak to each other?

As we design our form, we might come back to this list and rework it, combining or separating items, but this is a start. The questions yield specific-enough answers that we can start on the next step of our workflow: designing the order for our form.

Order up

The Post-It notes now placed in a logical order that our form will followAlthough the order of a form is always important, it’s especially crucial on mobile for a few reasons. Mobile users typically have a smaller screen size and don’t want to have to scroll up and down (or worse, side to side) to make sense of the form. Mobile users also typically also have their attention divided between their phone and other things going on around them; that’s kind of the point of mobile computing, after all.

For users with disabilities—especially those with motor and mobility issues, users with low vision, and those who rely on assistive technologies like screen readers or speech recognition software—the order of a form also has a huge impact on ease of use. Every time a user needs to scroll up or down to make sense of what they need to do is time they’ve lost to the interaction, and time they’re not eating their pizza.

The most important thing to consider when determining your question order is how to prevent users from going backward.

Typically, you want your questions to work like a funnel, going from most general to most specific, to help users get context for simple and complex forms alike. If your form has conditions, where some fields might appear or disappear based on user inputs, starting general and getting more specific also prevents you from doing gymnastics with code that might cause users to miss what’s happened, lose their place, or get confused. A user’s next step should always be the next one, not one or two steps back in the workflow.

With that in mind, let’s take a crack at ordering our form. There’s no right way to do this, but if we think about our party use case, we’ll figure out an order that seems to make the most sense.

  1. A pre-designed pizza, or a custom one? Whether your menu includes a list of pre-designed options or just custom ones, the first step to ordering a pizza is starting with the very concept of the pizza.
  2. Is cheese a topping? A default? While diligently researching pizza ordering websites for this article, I found some that treated cheese as a default, some as a yes or no option, and some as a topping. For our purposes, let’s say that users who want a custom pizza can order cheese or not.
  3. What toppings? The toppings make the pizza, and are going to be impacted by all of the user’s previous choices. They represent the make or break question in our workflow.
  4. Where do the toppings go? If our service allows users to split toppings, we need to consider whether users should pick a topping and then a location, or vice versa. To start, let’s try the first way, where users will pick a topping and then decide where it goes.
  5. What size? Size may be a general question, but it may also be impacted by all the other factors that come into play as customers figure out an order that best fits their current situation. For our use case, our customer might start ordering a small but find out a couple of other people are interested in the same pizza, and might readjust the size accordingly.
  6. How many pizzas? If your typical customers are ordering pizza in bulk, they may know they need ten right up front. However, for most users, they may not know how many they want until they’ve decided on the type and size of the first one (and until half the party decides to join in).

Into the kitchen

Now comes the tricky part: deciding how our questions are represented in the form. Each type of form element (radio buttons, checkboxes, select elements, buttons, text fields) is designed to display and collect data in a particular way, so it’s important to consider the element you use for each type of question.

Using native form fields means that mobile users will already be able to use your form, without any custom programming to support touch or keyboard interactions on your part, and form fields will be displayed with a size and appearance that they’ll be accustomed to in their mobile browser.

Since we’re picking one pizza at a time, and users need to see all options together, I think the recipe calls for radio buttons. These guys get a bad rap, but they’re perfect for situations where you need users to pick one of several options and you want them to see all the options at once.

See the Pen Pizza type by Devon Persing (@dpersing) on CodePen.

Next, users who selected a custom pizza need to make a decision about cheese, if the select a custom pizza. Since most users will want cheese, we can make this option selected by default. And since it’s a binary choice, a checkbox is probably the way to go.

See the Pen Cheese? by Devon Persing (@dpersing) on CodePen.

Next, toppings. We have two questions for each topping: whether a customer wants a given topping, and where they want it to go. Again, a checkbox makes sense for toppings since users can pick as many as they like, and will either want green peppers or not. Each topping can only be in one place, so we need a field that lets users make one choice from several.

We can use some CSS to give each field an accessible label but visually combine the two fields. While we don’t need it for our layout prototype, for a more streamlined experience, we also want to add some JavaScript logic to only show the location dropdown when a user has checked the topping box, so users don’t have to navigate through fields they don’t need.

See the Pen Topping options by Devon Persing (@dpersing) on CodePen.

Pizza size is straightforward—we’ll only offer a specific set of choices, which our users will be familiar with—so we can use a select dropdown. And finally, we need to let users order multiple pizzas for the type they’ve built. For our use case, defaulting to a value of one makes sense. Since the total number of pizzas will be a number (and probably not a big one; we’re a small shop after all!), let’s go with another select element.

To finish out our form, we also need a way to add another kind of pizza, and also allow users to get to the next set of questions to finish their delivery request. Both controls should be links, since they’ll navigate users to new content—they won’t submit the form yet.

See the Pen More pizza by Devon Persing (@dpersing) on CodePen.

Quality control

Don’t take your apron off just yet! To make sure our form still makes sense with our elements assigned, let’s review our workflow and see if it’s as straightforward as we hope.

Now that we’ve got elements mapped to questions, we might want to rethink our stance on cheese, since we’ve split our topping interactions into sides, and customers might want cheese on one side or the other. So, let’s add it to our toppings list after all!

To make sure we don’t miss anything, we also might want to add a “freeform” text area for users to include any concerns or special instructions they might have. This can go at the end of the form, since many users likely won’t use it, and for users who do, it will represent a specific need based on all of the other information provided.

So, here’s our complete, revised form, with our customer’s input:

See the Pen Pizza form by Devon Persing (@dpersing) on CodePen.

Customer feedback

picjumbo.com_IMG_0895The final step for our form is to put it in front of actual users, either in usability testing or live on the site. We can see how people respond and test different methods for the finer data collection points, like topping locations. If you’re starting out with usability testing for the first time, interactions you talked about a lot internally will often be good candidates for testing. Some things you thought were hard will be easy, and some things you thought were easy will be hard. There’s only one way to find out. Buon appetito!

The post Keyboard support for mobile: the tutorial appeared first on Simply Accessible.

Three common accessibility pitfalls for developers: information and relationships Thu, 24 Mar 2016 15:47:16 +0000 In the third post of her "Accessibility pitfalls for developers" series, Julie takes on information and relationships. This success criteria is about making sure that everyone gets the information, even if they can’t perceive the page the way other people can.

The post Three common accessibility pitfalls for developers: information and relationships appeared first on Simply Accessible.

After learning that our third most common accessibility problem was with images, and our second most common was with colour, both of which are abundant on the web, would it surprise you to learn that the most common problem we encountered during assessments last year was with HTML markup?

What we mean by “information and relationships”

In 2015, the highest amount of accessibility issues we found were classified under a specific guideline defined by the W3C: WCAG 1.3.1 Info and Relationships. This guideline requires that “information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.” Yeah, it’s a mouthful, and it’s not immediately obvious what it means.

When most people are using a website, they don’t just read the text for content and look at the pretty pictures. They look at the way the page is organized, with sidebars or highlighted areas, and the way things are styled or grouped. Designers use the visual appearance of elements to help us understand the structure of the page, and which items are related to each other. For example, check out this wireframe of a page.

A wireframe diagram of a product page. It doesn't have readable text, but the usual site elements like menu, images and forms are distinguishable from their shapes.

You can’t understand the content, of course, because the text is represented by squiggly lines. But you could probably point to the headings, the list and the alert message. This is because the designer has included visual cues to help you understand what types of information are available.

The Info and relationships success criteria is about making sure that everyone gets the information, even if they can’t perceive the page the way other people can. When we’re talking about information and relationships, what we’re talking about is more than visual presentation, we’re really talking about HTML.

HTML is the backbone of the web. Or rather, the forgotten backbone. Done right, HTML is humble. And because it’s “just markup” and not programming, it tends to get less time and attention than the more challenging languages, or whichever new framework was announced this week.

Sometimes programmers think that learning HTML is beneath them because it’s not real programming. But HTML markup is how people actually get the results of your programming. It’s the part of the web that connects your content to the whole world, so it deserves just as much care and attention as your programming and your server.

Results from our research

When I looked through the data from last year, I saw hundreds of accessibility issues caused by mistakes with basic HTML markup. People who had great content which deserves to be seen, but who had made a mistake in building their tables, or used spans to make a list, or didn’t realize what the hell the rarely-seen sup element is for.

A pie chart showing the percentages of the structure issues as described below.

You’ll see in the graph above that headings represented our biggest problem, totalling 35.92% of our issues with criteria 1.3.1. Tables were next at 24.27%. It seems people are still confused about when to use tables and when not to use them. Half of those issues reported were for tables being used for layout, and the other half were data being presented by divs or lists instead of tables. Speaking of lists, not using ordered and unordered lists were next with 11.89%. This was a bit surprising to me, because most WYSIWIGS and text editors provide good list tools. Forms made up 9.59% of the problems, which was mostly due to people using fieldsets and labels for their visual style and not for their semantic meaning. The navigation group (4.98% of the issues) included invalid markup on links, buttons, tabs, and menus, or divs and spans with scripting added. The Other category had 13.36% of the issues, and included a little bit of everything: extra paragraph elements used instead of CSS to create white space, deprecated elements, elements which were meant to be hidden, but showed up when a keyboard focused on them, and so on.

Why HTML matters for accessibility

People consume content in different ways, using different devices and different assistive tools. Web content, and its underlying structure, needs to retain its meaning when presented in these different formats. At Simply Accessible we check that the information presented by the website, and relationships between different parts of the website, can survive being transformed. We turn on high-contrast themes, we listen to the content using a screen reader, we resize the text, and we shove it into a variety of devices, because people might be using any sort of technology to view your project.

Luckily, browsers don’t just beam your site onto a screen—they also expose your carefully created HTML and content to an accessibility API. This can then be used by screen reader software to translate all of that information to speech, or by a Braille reader and keyboard to translate it to Braille.

When you use semantically correct HTML, you’re empowering people so they can find what they want faster and more easily.

When we write HTML, we have to let the browser know what type of content it’s dealing with and how that content relates to other content. By doing this, we let the browser and assistive technology like screen readers do their job: taking your content and giving it to anyone who’s interested in it, in any format they need. When software gets nothing but div soup, or elements used incorrectly, your page has no structure assistive technology can work with.

Screen reader software like JAWS or NVDA doesn’t just turn text into speech. It can use the information in the HTML to list all the headings on a page, so people can still skim ahead to find the section they want. Screen readers also give extra navigation controls to data tables, so people can review a row at a time, or jump to a single cell to get just the one bit of data they want. They announce how many items are in a list, so people can skip it if it’s not useful or search for the exact item they want.

Creating accessible information and relationships

My websites have semantic HTML as the base layer of everything I do. As Devon pointed out in her article about the accessibility stack, getting your HTML right makes the rest of your accessibility tasks so much easier. Let’s take a quick look at how to use HTML semantically so software doesn’t have to guess which parts of your content are important for your users and how they relate to one another.

Use container elements for layout only

Elements like divs and spans are for layout only. They’re semantically meaningless: divs create a display:block container and spans make a display:inline container, and that’s all they do. They don’t add any text styling, or have any size until you put more HTML inside them or add CSS. They don’t have keyboard or touch support in any browser, and they don’t communicate anything to the accessibility API. They just make a spot in your page where other things might happen. So, when divs and spans are used for headings or buttons (which both convey meaning and function), the browser can’t translate them into alternative formats with any functional purpose for someone using a different device to access your site.

Use other HTML elements the way they’re intended

All the other HTML elements should be used to tell the browser what functional purpose your content serves—not for layout:

  • Data goes in a table;
  • headings in h1 - h6 elements;
  • lists have list item (li) elements wrapped in ul or ol elements;
  • links (a) are for navigation, and buttons are for actions; and
  • inputs should only appear inside form elements, and should always have a label.

HTML elements provide meaning to the browser and assistive technology about what you’re saying on your website, so choose them based on what the content is, not how they look with slick graphics and CSS3 transitions. Old-timers might remember the CSS Zen Garden website: one page of HTML with hundreds of different looks thanks to user-submitted CSS. It demonstrates beautifully how content should be separated from presentation.

How much difference does proper HTML really make? Glad you asked!

Example: Heading will structure set you free

Say you need to scan the WCAG2 colour contrast guidelines and find out the proper contrast ratio for your brand colours. If you pop over and take a look at the W3C page, you’ll see it’s a pretty overwhelming wall of text. But a quick skim of the headings gets you to the right place in no time.

Screen reader software does exactly the same thing. It has a shortcut key which asks the browser to search the HTML for anything inside a h1 to h6 element. It sends that list back to the screen reader, which announces the headings, allowing a screen reader user to skim the page as quickly as you did, or even quicker if they’ve turned up the speaking speed to double-time.

A list of headings from a NVDA speech viewer for the WCAG page described.

If the W3C hadn’t used proper heading elements, you’d be stuck listening to stuff about pixel densities and ANSI standards for ages before you found what you needed. It might not seem like much, but using relevant HTML can make life so much easier for everyone.

Hide or do not hide: there is no try

When you remove something from the page, or disable it, make sure you’re really getting rid of it. Using CSS to grey it out, or make it transparent, leaves the element in the DOM and therefore available to the keyboard, touch devices, and assistive devices—even though you didn’t want anyone to use that control. To truly hide content, display:none is usually your best bet. I tend to put it in a helper class called hidden-all so I can apply it wherever I need it. And if you want to put in some visually hidden notes just for screen reader users, I like to make a class called hidden-visual. Those look something like this:

.hidden-all {
   display: none;

.hidden-visual {
   border: 0;
   clip: rect(0 0 0 0);
   height: 1px;
   width: 1px;
   margin: -1px;
   padding: 0;
   overflow: hidden;
   position: absolute;

If in doubt, check it out

Obviously, on the Internet we have some excellent resources on the HTML elements which form its backbone. The Mozilla Developer Network has a HTML reference with documentation, plus tutorials from beginner to advanced. Jeffrey Zeldman’s Designing With Web Standards is a classic on how to make the most of your HTML. Or you can ask your friendly accessibility expert!

In 2016, I’d love to see people who build the web make a commitment to becoming expert in HTML as well as the the newest frameworks and libraries.

If there’s any aspect of HTML accessibility you’d like to know more about, leave us a comment here and we’ll write a post about it. If you’re making one of those frameworks and libraries, please do make sure your HTML supports the structure of the content—you have the opportunity to set a good example for people who are just starting out in the wonderful world of the web.

The post Three common accessibility pitfalls for developers: information and relationships appeared first on Simply Accessible.

Why “managing accessibility” doesn’t work (and how to do better) Thu, 10 Mar 2016 23:46:43 +0000 The wheelchair access ramp was blocked by more than a foot of snow…and two potted trees. I was bemused and frustrated at the same time.

The post Why “managing accessibility” doesn’t work (and how to do better) appeared first on Simply Accessible.

One snowy winter day, I went to the pharmacy to buy cold medicine. I couldn’t get into the store.

Pharmacy entrance with snow and trees blocking the ramp

The wheelchair access ramp was blocked by more than a foot of snow…and two potted trees. I was bemused and frustrated at the same time. Bemused because the situation was ludicrous; frustrated because I really needed that Sudafed.

Obviously, at some point, someone made an effort to make the store accessible. And just as obviously, at some point, someone else plain forgot. It’s a more common problem than you’d think.

Accessibility that needs ongoing maintenance all too often leads to failure.

The downward spiral

Another illustration. The city council wanted me to present my analysis of the renovation plans for a civic building. The council chamber was on the second floor of a building with no elevator–incidentally, access to the council chamber was one of the items up for discussion.

To get elevator access, people needed to go to the building across the street, take the elevator to the second floor, and then cross the street again via a skyway. The door to that building was locked after hours. If you needed access, you had to ring a bell and someone would come, open the door, and escort you through the locked offices to the council chamber.

I’d arranged ahead of time to have a security guard waiting for me at the door in time for my presentation. I arrived at the appointed time, but no one was there. I rang the bell, and waited. No one showed up. Half an hour later, I connected with someone by phone who sent someone to open the door…but they couldn’t find the key. Needless to say, I was late for my presentation and the city council’s good accessibility intentions fell way short.

These kinds of things happen all the time both in the built environment and online. We build something, and for one reason or another, we leave accessibility until the end. It’s tacked on as an afterthought, or we rely on third party solutions to fill the gaps. We end up with something that might pass as accessible, but it needs ongoing maintenance to stay that way. The snow needs to be shoveled from the steps and that new ramp. We have to figure out where to store those potted trees in the winter. We have to make sure there’s staff on duty, and that they have the right key. We build forms and modal windows, but when the site is redesigned, these aren’t updated. Or different parts of our sites use different vendor applications that aren’t keeping up with accessibility improvements.

More work for everyone

With after-the-fact approaches like this, there are many small parts, actions, or processes that need to happen consistently in order to ensure accessibility. Each and every one of these parts is vulnerable to failure, increasing the likelihood that the accessible solution ends up not working as expected. We get busy, or the people maintaining the accessibility solution get reassigned to another team. We change something on our site or in our code, but the changes aren’t carried through to the accessible solution. Accessibility slips through the cracks.

In the 90’s, an accessibility solution that got some traction was providing a no-frills, text-only version of a site linked to from the main site. Invariably, after a time, updates made to the “main” site weren’t reflected on the “accessible” site. People relying on finding information on the accessible version of the site couldn’t find up-to-date information, or were unaware that the information was outdated. Not to mention that text-only formats aren’t accessible for everyone—some people rely on visual formats to parse information. There’s also lost functionality when going to text-only formats, so it’s just not a holistic solution. What’s intended as a separate-but-equal experience is, in fact, just separate.

The more you have to prop something up with human effort, the more likely it is to fail. In the words of Dr. Horrible, “The status quo is not quo.”

Integrating inclusion

Solutions that require extra caretaking come from the right intent, but they fall short when encountering real life. They fall down because they’re managed by people. And people are, well, human.

Managing accessibility like this takes a lot more effort than integrating accessibility into your process from the beginning.

The pharmacy owners could have removed the snow from the ramp before shovelling the stairs. Then everyone could have used the ramp. This isn’t the best fix, but it meets everyone’s needs. The better strategy is to build the store level with the sidewalk, and have a no-step entrance providing access for everyone equally. Fix it once, fix it for good.

Cartoon illustration of children talking to the custodian shoveling stairs.

Child in wheelchair with other children standing nearby: “Could you shovel the ramp, please?”
Adult shoveling stairs: “I will as soon as I clear the steps. A lot of kids want to go up.”
Child : “If you did the ramp, we could ALL use it.”

Ideally, your team discusses strategies for creating accessible products right from the first planning meeting. The designer creates a colour palette with accessible and beautiful contrast. The development team contributes to a pattern library, so they’ve always got accessible components at their fingertips. Product Owners create inclusive use cases for product specifications and user stories. And the whole team gets behind testing with real people to make sure your creations work for actual users.

But, more likely, you’re reading this while in the middle of an ongoing project with code and designs you inherited. Maybe you’re the only one on the team thinking about accessibility. And so this is where you start. Why? Because it’s the right thing to do!

Implementing accessibility as you go is a reality, but to be really successful in the long-term, keep seeking out accessible solutions that don’t need the extra hand once they’re built and live. Don’t let the responsibility fall on to only one person (or one small group)—Involve all team members in this process. Everyone creating products contributes to accessibility. Use the power, skills and knowledge of your team to identify possible barriers and rectify them, building those insights into accessible pattern libraries.

What have some of your aha moments been while creating or designing lasting accessible solutions that work for everyone? Share in the comments below.

The post Why “managing accessibility” doesn’t work (and how to do better) appeared first on Simply Accessible.

]]> 2
Love letters, part two: a post-retreat retrospective Tue, 08 Mar 2016 21:32:31 +0000 The Simply Accessible team is back from our retreat in central Florida. We're inspired and energized—ready to take everything we've learned to build a digital world for everyone.

The post Love letters, part two: a post-retreat retrospective appeared first on Simply Accessible.

We gathered. We ate our collective body weight in oranges. We laughed, we cried. (Actually, no one cried except Melanie, who “just cries a lot” anyway.)

Our team retreat was wondrous. The palm trees and hazy sunsets contributed to the magic, but it was connecting with each other and Simply Accessible’s beating heart that made our experience truly exceptional.

We’re excited to share with all of you what we’re taking home with us, and how it’s inspiring us to be better and do better at making the web a more inclusive place.

Scott explains the cool error alert he just made, while Derek looks on, enraptured. Meanwhile, Charles scrum masters masterfully.

Derek Featherstone, Simply Accessible founder

The most significant takeaway from the retreat for me was that effective teaching and learning is not about one person telling another something. It’s much more effective to model the behaviours and skills you want people to have than it is to simply tell them what you want them to do. When a job requires a particular way of thinking, you need to model that thinking and make it overt—expose the way you’re thinking about a problem and provide insight about the decision making process in your head.

Going forward, I want to change my thinking to move from “How should I teach this?” to “How best will people learn this?” I’d like to ensure frameworks are in place that enable people to be active participants in their learning, where the control over learning rests more on what the learner is doing than on what the teacher is doing. That goes for speaking engagements, on-boarding new staff, and our work with clients.

Elle Waters, Director of strategy

Individually, each person on our team is quite creative, but I already knew that. Collaboratively, however, I learned what a powerhouse of innovation we are when we combine our ideas. I plan to look for more opportunities this year where our whole team can brainstorm, working together on new ideas, and finding new ways to solve design and usability problems.

Jeff Smith, Director of operations

My most significant takeaway was the concept of “the butterfly effect.” How everything we do individually, as well as a team, has an effect on our clients’ success as well as Simply Accessible’s mission. Something that can seem incredibly small, like adding a code example to clarify an accessibility recommendation, could have a huge impact. A couple lines of code could be the turning point for a developer embracing accessibility.

I want to apply this insight to my work now by being more deliberate with everything I do, whether it’s a deliverable for one of our clients or related to our own, internal processes. I want everything we do to matter and contribute to our mission and our clients’ missions.

Joanna Briggs, Manager of accessibility and usability testing

Being a remote team, we’re connected, but there’s a little bit missing until you first meet someone. At the retreat, I got to see all of the talent and passion that each member of our team has in person—there’s no hiding it. We had time to take a big step back and look at the bigger picture. After that, it was great to collaborate with people on concrete work. I’m looking forward to all the things we’re going to accomplish together.

Caught in a moment of angelic afternoon sunlight, Joanna and Charles embody the team’s optimism and good taste in laptops.

Charles Callistro, Scrum master

I think my big takeaway was the realization that we’re all on the same page in regards to sharing and affecting each other’s workload. I went home pretty satisfied that we’re going to be clearing up some bottlenecks! Now, on the other side, I’m going to use the clarity I got from the roles exercise to help direct traffic to the right people for the right tasks.

Devon Persing, Accessibility specialist

My major takeaway is how much I like everyone, truly and deeply. Its application will be continuing to want to impress, collaborate with, and do amazing stuff with this team. Also, I’m amazed at just how much we got done. I feel excited about going “back” to work.

Tom Pokinko, Product owner

There were many great teaching moments and collaborative sessions where the energy and creativity of our team really shone. Perhaps the biggest takeaway for me, however, was seeing the way our team not only payed careful attention to what needs to be done, but set a gold standard for the way it’s done: with care, compassion, a willingness to listen, and an overall dedication to excellence. Going forward, this inspires me every day in my interactions with our clients. I’m inspired to provide a wonderful customer experience with a shared dedication to accessibility at the fore!

Gavin Ogston, Accessibility specialist

The most significant take away for me was just how passionate each team member is about accessibility. Also, how important it is to always be thinking about how our feedback addresses the emotional state of the team member or client receiving any feedback. How moments like this are opportunities to fire up some passion about accessibility.

I plan to apply these insights to my work now by adjusting the way I present feedback and assessment, so that whoever’s on the receiving end can be inspired and empowered.

Nicolas Steenhout, Accessibility specialist

The most significant takeaway for me was how the power of the team is significantly more than the sum of its parts. I’ll apply this by seeking regular feedback and brainstorm sessions with other team members.

The incredibly good-looking and passionate Simply Accessible team!

Scott Vinkle, Accessibility specialist

As a new person on staff, the most exciting takeaway for me was the fact that Simply Accessible actually does user experience testing with real people in their own environments on a regular basis! This important piece of testing is almost always overlooked within other organizations, which often leads to poor user experiences for people with disabilities. Joanna shared the knowledge that’s been collected from these sessions, and we discussed her findings within the company as a whole, creating a large knowledge base of practical and useful information.

It was great to be be a part of that, to share and absorb the knowledge that everyone has. From here I’ll be able to increase my own skill set through these discussions. I’m also able to apply this knowledge and improve the user experience for anyone using components we help to improve.

Melanie Jones, Editor and content strategist

The most significant takeaway for me was about the importance of asking the big questions. The mission and vision questions. In the day-to-day grind, we get wrapped up in hitting deadlines; it was extremely important to take the time and reconnect to our deeper purpose. Bringing the big picture back into view not only inspired me, but it made me see how I want to up my game as we go forward.

I’m going to apply it by bringing those bigger questions into my work every day. How does every piece of content we produce make the digital world better for everyone? How can everyone who contributes be an ambassador? A blog post isn’t just a blog post—it’s a small part of a larger vision.

What do you want to see more of from the team at Simply Accessible? How will you bring your best to what you do for the digital world? Share your ideas in the comments.

The post Love letters, part two: a post-retreat retrospective appeared first on Simply Accessible.