October is National Disability Employment Awareness Month, or NDEAM for short. The purpose of the event is to celebrate the contributions of people with disabilities in the workplace. If you’re reading this, there’s a decent chance you haven’t observed the online experiences of a screen reader user like myself, so let’s break down “a day in the life of Patrick” for you.
Recently, I was in a meeting discussing projects, client needs, and general work items required to provide great service to our Deque customers. The topic of scheduling time when working with clients that are external to the Deque organization came up and it was suggested I try out a new scheduling tool. This is one of those scheduling tools that help solve the problem of juggling everyone’s calendar no matter where the individuals are organizationally located. I received a link to the product and began to enter my “let’s go into battle” mode mindset which is the norm for new sites that I haven’t ever visited.
My “new site” reconnaissance efforts
When approaching a new site these are some of the items I review:
- The general site layout: Using my screen reader, I look at how to navigate the content offered through various links and navigational features like headings, menus, search bars, and tabs
- The graphics that are labeled: This often provides an understanding of the site’s message
- A review of the accessibility statement, if applicable
Once I obtain a high-level understanding of what the site offers and the basic layout, it’s time to roll up my sleeves and use the site to do real work, whether that be looking information up or performing a transaction. In my case, I was going to look up when my colleague was available on a specific date in order to exercise the functionality of the site.
Diving into core content and functionality
Normally, this can take from 5 to 30 minutes depending on how complex the site is. I hit the link provided and was presented with a clean simple page that, right off the bat, was giving me the information I wanted to see.
No fancy navigation bar, no search box, no scrolling carousel, no ads, and no extensive list of links to other pages. It simply provided the user’s name and a list of meeting types that I could select from to search for a time block for the user. I selected the “30-minute meeting” link and received another well-organized and accessible page with a backlink and a simple-to-use calendar with controls to allow me to easily change the month.
The calendar was displayed in a table, which always makes me happy because it allows me to easily navigate the days in a grid format permitting me to select the day by moving right/left and then move down a column of dates until I find the one I need. Each movement clearly announced the day and date I landed on and that it was a button I could use to select. Once the button was pressed, I hit “H” to trigger my screen reader to provide the list of headings, down to the list of available times.
I won’t walk you through the entire process, but trust me, it all worked smoothly and I was able to submit a meeting request through the site. I liked it so much I asked for my own account and the screens used to set up my preferences were just as accessible, clean, and straightforward to use and navigate.
A look at the native mobile experience
This time, follow along with me on one of my mobile experiences on the iOS platform. While this isn’t a workplace experience, it is fairly representative of many of my experiences.
This experience started a while back when I purchased concert tickets on a relatively accessible website and all went well. Now, the date for the event starts to get close and email reminders start to come into my inbox informing me of the pending date and the fact that tickets purchased online are only good at the venue if displayed on your phone. No printed tickets are accepted.
Learning this, I download the ticket distributor’s mobile app ready to log in and download my tickets to place them in my digital wallet. I easily hit the link in the email to take me to the app store to download the application and open it up.
Once the app was on my phone, it opened and I received a blank screen. I’m not used to this so I check to make sure I have the right app. I close, relaunch it and am still presented with a blank screen that accepts no Voiceover gestures and no verbalizations as I slide and swipe all over the screen. The only thing that talks is the status bar at the top including the time. It appears now that I have time I wait until I can get sighted assistance to tell me what is up with this app. This is not what I was expecting.
The day comes when I have some eyes to help take a look, so I reopen the app and confirm the experience is still problematic and hand my phone over to the “pros in the vision department”. I am told there are disclaimer screens–5 of them–that have to be answered. All disclaimer screens aren’t accessible, so my friend answers the simple questions in a matter of a minute and the main app appears that has the login feature.
The app then becomes fairly accessible but does have keyboard issues on the login screen that require sighted assistance. Once I was logged on, I was able to find my event and the associated tickets I purchased. From there, I was able to view and download the tickets to my mobile wallet.
For most iOS apps I encounter, at worst, I can figure out workarounds. This app surprised me because it was a major blocker in the “get the job done” department that I could not come up with a way to battle through. What made it worse was my alternative (hardcopy tickets) was not an option. When leading a digital lifestyle that requires assistive technology to make it all happen, you never know what good or not-so-good surprises will come your way.
Where are the Accessibility Statements?
You may have scrolled past these along with Legal terms, Privacy terms or other links that get buried in site footers. Check out Deque’s Accessibility Statement if you are looking for an example. Inside this page, you will find some statements about an organization’s commitment to practicing digital accessibility.
You might also find VPATs or “Voluntary Product Accessibility Templates”. VPATs follow a very specific format, which communicates the state of conformance of that site or product against guidelines like WCAG. This essentially provides deeper insight into the accessibility of the services that the org offers and is a stellar way to let me know what to expect.
While both of the experiences I reviewed above demonstrate some extremes on the digital accessibility spectrum, what they have in common is that they both don’t have accessibility statements. Why not? They certainly have sitemaps to help Google bots crawl, navigate and index the site. Why not provide that same guidance to millions of other assistive technology users like me?
I’d love to change my “new site” reconnaissance process to just “read accessibility statement,” then “use site.” And as we make collective progress in improving digital accessibility as the default, maybe we can eliminate my recon efforts entirely.
Final Thoughts
My experience with the scheduling app leads me to believe that, over time, increasingly great experiences will be had by all when it comes to accessing all that the internet has to offer. Obviously, the experience with the ticketing app could have easily been avoided if the developers had performed a simple swipe test using Voiceover, as it would have quickly stopped their testing path and alerted them to request a fix. Through the work we are all doing for digital accessibility, we are creating more positive experiences than negative ones, allowing every one of us to lead an inclusive digital lifestyle no matter what technology we use for assistance.