#ecommerce, #retail, #accessibility, #a11y, #inclusivedesign, #wcag, #personas, #ux
By Miguel Estrada, UI Developer at SAP Customer Experience Twitter: @developpeur
The Tale of a Yellow Scarf
This is another delivery of the Web Accessibility series I started a while ago, in case this is your first read, I’ll introduce myself briefly. I started as a Web Designer and have been a Front-end Developer for over 20 years now, but recently became a Web Accessibility enthusiast in 2014. This is because, once upon a time, a company I used to work for landed a Web Accessibility project, and volunteers for owning the topic were scarce, so as the lead front-end developer back then I pretty much had to. Also, around that time I had my first dark dining experience (don’t ask how it went) and since then I became fascinated with the topic, not only it helped me to be a better developer, but also made me realize a wider range of possibilities as a user experience advocate, as a web designer, as an everyday user of websites and apps, and as human being by raising my empathy levels.
Although this article is mainly aimed at Web Developers, Quality Assurance testers, Product Owners, Managers and UX Designers, yet I’m sure it will be interesting enough for any reader who likes engaging in hands-on experimentation.
The Accessibility Dilemma
Success criterions for web accessibility under WCAG 2.0 (Web Content Accessibility Guidelines) could be overwhelming if seen only from the textbook perspective, in my experience developers and managers have almost unanimous discomfort reactions to Web Accessibility projects: do we have to read “all that”, it’s just “so boring”, “run the validator” … crickets and tumbleweeds to sum it up.
As a developer and learner of Web Accessibility, I realized that once passing the “excruciating pain” of reading the criterions, I started to understand that this can be approached from different angles, from the User Experience one for instance, and also by layers… slowly, but really… by just testing. Something developers do very often. Now, that usually gets me into the following Q&A:
But what do we need to “test” exactly?
What we unconsciously do most of the time: the user journey.
How do we do that?
We need to consciously empathize with the disabilities our users may have, in other words simulate.
Isn’t enough to test my site with a validator?
No, validators are indeed of great assistance when analyzing large websites for some criterions. Yet, I’ve seen validators passing sites with flying colors only to realize they are, in fact, not accessible hands-on.
Concrete analogy please?
Believing that just because you comply with a few criterions makes you website accessible to “a certain level” is like thinking your office building is “accessible” because it has an automated handicap door opener at the main entrance … but only after passing through a gravel parking lot and climbing a staircase.
An Accessible Storefront
Many sectors are subject to Web Accessibility compliance these days, for some —like government— is mandatory. Online retail has become the target of a growing number of lawsuits, also users with disabilities have clear expectations, therefore a growing need for accessible storefronts is on the rise. By “storefront” I mean the online version, aka shopping cart or a commerce Website.
Let’s illustrate the process with an example, but first establish some premises:
1. Main goal of a storefront is to allow users to checkout products.
2. Elements on the interface should facilitate the user to complete a checkout, including users with disabilities.
3. Developers and Quality Assurance Testers often test by pretending a user can successfully get from point A to B or Z on the interface. Same folks should test that users with disabilities are able to get to the same points.
4. Successfully getting from point A to B or Z in a test, while emulating a Persona with disabilities, will result in a number of successfully complied accessibility criterions.
Before getting into what a Persona is, let’s clarify empathy. It sounds like something easy to do, we’ve heard it many times: “put ourselves in somebody else’s shoes”, how hard could it be? Well, turns out people have different levels of empathy, and are usually influenced by their own life experience … so it’s not that easy.
Also, different perceptions of what empathy means complicates things, I’ve heard many spontaneous definitions: it’s about having a big heart, being all sentimental about something, a philanthropist, or reading emotions “between the lines”… yes, I guess it could very well be all that depending on the context of the conversation, but when talking about Web Accessibility, empathy is luckily a very pragmatic issue… an online storefront is either accessible or isn’t, “half accessible” doesn’t do if a critical journey is not successful, as wouldn’t do for a brick-and-mortar store, either shoppers with disabilities can or cannot get in and make a purchase.
My usual story to “induce” people into empathy is as follows, let’s add a relaxed atmosphere first and pretend we are in a restaurant or a bar, surrounded by family, friends or occasional bystanders, usually the context where I tell this story:
Pretend you (a user without disabilities) are shopping online for simple product, such as let’s say… a yellow scarf for women, and suddenly your computer mouse stops working —battery runs out— and you have to finish the checkout using only the keyboard.
Of course, there is always resistance to this empathy exercise: because “what if I’m using a laptop that has a built-in mousepad” … let’s agree that’s not the point. It may sound like nonsense having to empathize in something as banal as having a mouse, but it’s relevant to the full process, also I have to point out a generational factor in these casual audiences of my stories; let’s keep in mind that users that owned a computer in the mid 80s may recall how to move on the screen with a keyboard, back then ball mice were only starting to be introduced and it wasn’t until the late 90s that optical mice became commercially available, but users that were born in those decades may be caught off guard envisioning a keyboard-only scenario. As I said, not so easy to empathize.
Anyway, once the example is assimilated and people start throwing theories and remembering or figuring out how to move on the screen using only the keyboard, then we will have an idea, a plan, a roadmap —a journey— on how to finish the checkout.
Ok, once this keyboard journey is assimilated, let’s add complexity: Let’s pretend you have purchased this item many times (get yellow scarves for everyone) and now you know the process by heart, “so good” you can do it without a mouse, so good you can do it “with your eyes closed” … really? … let’s try that: keyboard navigation + eyes closed.
Personas with Disabilities
Before closing your eyes, let’s define what a Persona is; In the context of User Experience (UX) Design, “personas” are archetypical users whose goals and characteristics represent the needs and limitations of a larger group of users. Yes, putting faces to users helps with the empathy process, by googling “personas for accessibility” we can find many readily available personas to use, but then yes, more reading … crickets and tumbleweeds again.
That said, to follow-up on the casual oversimplified storytelling at the bar, and since this article is starting to be long (missing the point of not having to read that much) let’s just oversimplify in a short paragraph a couple of personas that can be easily emulated by users without disabilities. Enter Jane & John, coming from a previous article, they have helped me before when setting accessibility foundation perspectives, and expectations.
- Jane: right-handed user, recently broke her right hand, has to use keyboard-only navigation, relies on her sight to know where she’s at on the screen, and for getting to the next element in a User Interface.
- John: blind user, uses keyboard-only navigation, relies on a screen reader vocalization to know where he’s at, and to get to the next element in a User Interface.
Critical User Journey
There are many ways a user can navigate a storefront, but there are always paths that are more common, those where the storefront actually make money are the critical user journeys. Keyboard-only navigation is no exception to this, so let’s agree on an average right down simple journey based on the product from our story, a yellow scarf for women.
Test use case: Jane is looking to buy a yellow scarf for herself and John wants to buy the same scarf for her girlfriend.
For both, Jane & John, the critical journey to buy a yellow scarf for women will look something like this:
Tab to Search field > type “Yellow scarf women” > Tab to the first product (pretending is the yellow scarf) > Start the checkout process.
We’re getting there, thanks for reading this far. Now, imitation is key to empathizing, and we need to do that as close as possible as to how Jane & John will navigate to that yellow scarf in a storefront. We know both will be using keyboard-only navigation, so that leaves us with the following keys to complete the checkout:
- Arrow keys.
Additionally, John will need a Screen Reader, usually a pricey software with many features, luckily we can emulate the basics of this technology by installing the ChromeVox extension to your Chrome Browser.
Ok, this is where I dare the bar’s audience and you, the reader —just kidding— I kindly invite you to choose any, or several, online storefront out there in the web where you can find a yellow scarf for women and try to reach the checkout by emulating Jane & John. That said, you don’t “actually” have to buy the scarf every time, not if you don’t want to.
Follow the critical user journey using only the keyboard keys Jane would use.
Activate the ChromeVox extension and —finally!— do close your eyes, and follow the critical user journey by listening what the vocalization tells you and by using only the keyboard keys John would use.
As you compare your emulation experience throughout storefronts you may run into issues such as: being unable to tab to the next logical element in the page by landing on random elements, unable to tab from any point forward (keyboard trap), unable to hear a meaningful description of the product, like its color or its price. Sadly, this is very common and an indicator of the lack of Web Accessibility in a particular website.
But, if you have managed to successfully finish the checkout process by emulating Jane & John, then that storefront has complied with the following WCAG 2.0 criterions.
Notice how most of the criterions are Level A with only a couple of Level AA. In my opinion those above are the most important criterions to comply with, because they set the foundation for building a richer user experience on top of them, that is more Level AA criterions, plugging other assistive technologies like braille displays, but also, they are independent from “simpler” criterions like those regarding use of color, text size, video and audio.
Well, this is where the story at the bar ends, either if you were able or not to finish the emulation as Jane & John, even if you just tried a little, it deserves a toast as you may have realized by now that by closing your eyes you began to “see” where the problems are. So, cheers to that! with whatever you were drinking.
1. We can validate Web Accessibility by “walking the walk” with empathy.
2. When planning, developing and testing an online storefront, any effort in the process to remove bugs related to the 16 criterions stated above will facilitate the checkout for user with disabilities.
3. A web developer should make sure an accessible critical user journey actually works before handing it over to the QA tester.
4. The best validation tool is empathy.
5. Sometimes by closing our eyes, we can “see” where the problem is.
6. Shoppers with disabilities should be able to purchase online as they do in brick-and-mortar stores.
7. Nobody is exempt from disabilities through a lifetime, best case scenario: we all age.
8. Web Accessibility should be seen as a business opportunity in any lead-to-cash strategy, before it becomes a lead-to-lawsuit scenario.