Storefront Accessibility

Reading Time: 8 minutes
woman wearing a yellow scarf next to a male blind user
An artistic illustration shows a collage of images. A woman wearing a yellow scarf and a black jacket with a watermarked web accessibility logo. A male blind user over a keyboard background. A hand with a bandage cast. A dollar sign connects all 3 images.

The Accessibility Dilemma

Success criteria 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. Such as: do we have to read “all that”, it’s just “so boring”, “just run the validator” …  crickets and tumbleweeds to sum it up.

As a developer and learner of Web Accessibility, I realized that once moving past the “excruciating pain” of reading the criteria then it can be approached from different angles. From the User Experience angle for instance, and also by layers. Slowly, but really, by just testing it. Something developers do all the time. 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?

By consciously empathizing with the disabilities our users may have, in other words, simulate or emulate.

Isn’t it enough to test my site with a validator?

It’s not. Validators are of great assistance when analyzing large websites for some criteria. Like 20% of them only. However, I have seen validators passing sites with flying colours only to realize they are, in fact, not accessible hands-on.

Concrete analogy, please?

Believing that just because you comply with a few criteria, makes your website “accessible” to a certain level. Would be like thinking your office building is “accessible” because it has a very big button to open the door automatically at the main entrance … but only after passing through a gravel parking lot and climbing a staircase. So how does the user make it to the door for starters?

Storefront Accessibility

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 Storefront Accessibility is on the rise. Sometimes making the difference between a “lead-to-cash” approach to a “lead-to-lawsuit” outcome.

Premises

Let’s illustrate the process with an example, but first establish some premises:

  1. The main goal of a storefront is to allow users to checkout products.
  2. Elements on the interface should facilitate the user to complete 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. The same folks should also 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 criteria.

About Empathy

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 experiences… so it’s not that easy.

Sympathy is NOT Empathy

Also, different perceptions of what empathy means complicate things, I’ve heard many spontaneous definitions: it’s about having a big heart, being all sentimental about something, being 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 still, all the aforementioned are closer to sympathy than empathy. Now, when talking about Web Accessibility, empathy is luckily a very pragmatic issue. For example, an online storefront is either accessible or isn’t. In other words, “half accessible” doesn’t do if a critical journey is not successful. As it wouldn’t do for a brick-and-mortar store. Either shoppers with disabilities can or cannot go in and shop.

Regardless of how one “feels” about the fact, our good intentions, thoughts and emotions poured into thinking about the users who are unable to use the storefront won’t make it more accessible. That’s sympathy. It’s nice. It’s motivation. It helps. It raises awareness. But it doesn’t make websites accessible.

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 a simple product, such as let’s say… a yellow scarf for women, and suddenly your computer mouse stops working —its battery runs out— and you have to finish the checkout using only the keyboard.

Resistance to Empathy

Of course, there is always resistance to this empathy exercise, and it’s normal, we are placed out of our comfort zone. So I hear things like: “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.

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 with.

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, know it “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 get long (missing the point on 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, who 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.

The tale of a yellow scarf

There are many ways a user can navigate a storefront, but there are always paths that are more common, those where the storefront actually makes money are the critical user journeys. Keyboard-only navigation is no exception to this, so let’s agree on an average super simple journey based on the product from a story on Storefront Accessibility, a yellow scarf for women.

Critical User Journey

Test use case: Jane is looking to buy a yellow scarf for herself. On the other hand, John wants to buy the same scarf for her girlfriend. To further clarify, Jane & John, are not related, not they know each other.

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.

Emulate or Simulate?

We’re getting there, thanks for reading this far. The difference between simulation and emulation is subtle. Since they both include the word “imitation” let’s stick to that concept. For the following example, we are going to be using emulation software, so let’s call it emulation, but know that I definitely mean imitation.

Now, Imitation is key to empathizing, and we need to do that as close as possible 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.

Keyboard Interactions

  • TAB
  • SHIFT+TAB
  • SPACE
  • ENTER
  • Arrow keys.

Additionally, John will need a Screen Reader, a stand-alone software with many features. Also with an important learning curve. Luckily we can emulate the basics of this technology by installing the ChromeVox extension in your Chrome Browser to emulate a Screen Reader. It has to be said that, no extension to this date, has as many features as a full-fledge Screen Reader software, such as JAWS, NVDA or VoiceOver.

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 storefronts out there on the web. But most importantly, one where you can find a yellow scarf for women and try to go as far as you can through the checkout process by emulating Jane & John. That said, you don’t “actually” have to buy the scarf every time, not if you don’t want to.

Emulating Jane

Follow the critical user journey using only the keyboard keys Jane would use.

Emulating John

Activate the ChromeVox extension and —finally!— do close your eyes, and then follow the critical user journey by listening to what the vocalization tells you, and by using only the keyboard keys John would use.

Common issues

As you compare your emulation experience throughout different sorts of storefront accessibility, 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 colour or its price. Sadly, this is very common and an indicator of the lack of Web Accessibility on a particular website.

Criterion compliance

Clarification of terms: criteria is plural; criterion is singular.

Now, 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 criteria.

OrderEmulated userLevelCriterion observed
1Jane / John A2.1.1 Keyboard
2 Jane / John A2.1.2 No Keyboard Trap
3 Jane / John A2.4.1 Bypass Blocks
4 Jane / John A2.4.3 Focus Order
5 Jane / John AA3.2.3 Consistent Navigation
6 Jane / John AA2.4.7 Focus Visible
7JohnA1.1.1 Non-text Content
8John A1.3.1 Info and Relationships
9John A2.4.2 Page Titled
10John A2.4.4 Link Purpose
11John A3.1.1 Languages of Page
12JohnA3.2.1 On Focus
13 John A3.3.1 Error Identification
14 John A4.1.1 Parsing
15 John AA2.4.6 Heading and labels
16 John AA3.3.4 Error Prevention
Table showing 16 criteria for the Successful emulation of Jane and John. The first 6 criteria are for Jane and John, the remaining 10 only for John)

Notice how most of the criteria are Level A with only a couple of Level AA. In my opinion, those above are the most important criteria to comply with “for starters”. They set the foundation for building a richer user experience on top of them. For example, adding more Level AA criteria, or plugging other assistive technologies like braille displays. Let’s consider them the hard part, or independent from “simpler” criteria, like those regarding the use of colour, 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, by closing your eyes you began to “see” where the problems are with Storefront Accessibility. So, cheers to that! with whatever you are drinking.

In Conclusion

  1. We can validate Storefront 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 criteria stated above will facilitate the checkout for users 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.

CSS grid vs. Web Accessibility

Reading Time: 5 minutes
web accessibility logo trapped in a grid
Artistic illustration showing a web accessibility logo trapped in a mesh fence.

CSS Grid could create accessibility issues if not used with prudence. It gives great power over the User Interface (UI) layout. But if we lose touch with the source order, then the User Experience (UX) could end up not making sense for users either with or without disabilities.

Web accessibility awareness is growing due to its costly consequences if omitted. More and more unwary retailers or content providers exclude their clients and users by overlooking their disabilities. This growing trend is becoming close to an act of discrimination. Besides the liability side, organizations could be missing out on revenue, audience and human resources by this omission.

As a UI Developer, part of my work is to test new layout implementation approaches for web applications. Always keeping in mind the needs of our clients and their users. With the clear mission of providing a comparable UX journey for users with and without disabilities.

Comparable UX

Providing a comparable UX is not easy, it’s a challenge to balance visual order vs source order. The visual order is that in which the elements of a page are being visually rendered on the screen. However, it may not necessarily correspond to the source order. Being the one in which those same elements appear in the code. Visual perception is two-dimensional and non-linear; the desired visual order is not always equivalent to the desired reading order.

Keyboard-only users could navigate (tab) their way through page elements. Then finding themselves jumping from top to bottom of the page due to a reordered element being next in line in the source order. This gets worse if for some reason the tab order is altered with “tabindex”. Then pointing towards elements in a specific order when implementing group skipping.

This could grow in complexity when adding breaking points. When elements get reordered for many screen sizes. Mobile assistive technologies like VoiceOver for iPhone (gesture-based screen reader) offer multiple ways to navigate a page. Either by headings, by links or by landmarks among other options.

Visual order vs. Source Order

Disconnection between visual order and source order is not a new topic. It was already spotted with the “position: absolute” declaration a decade ago. Same for Flexbox and now CSS grid. Although this is a known issue, unsurprisingly there isn’t enough awareness about this matter. It is only when targeting Web Accessibility that this actually becomes “an issue”. Especially because source-order independence is a wanted feature in CSS-grid.

So, this article aims at bringing more awareness by spreading the word on the Accessibility Interference issue. It is mainly aimed at Web Designers, UX Designers, Frontend/UI Developers and Product Owners. If you are looking for answers and suggestions on how deep to implement CSS grid. Or if it’s worth implementing it at all (having Web Accessibility as target).

Quick reminder: CSS grid does not replace Flexbox, they work on different dimensions. CSS grid is for ordering items in two dimensions: rows AND columns, whereas Flexbox is single-axis oriented: either rows OR columns.

css grid vs flexbox comparison
Illustration showing axis orientations for CSS Grid and Flexbox

That said, it’s clear we need to resist the temptation of using CSS grid for placing just about everything on a page only because it’s possible… but let’s do that anyway for demo purposes. Let’s pretend we’re building an e-commerce storefront with CSS grid and we totally overlooked Web Accessibility.

Source order matters

For the purpose of this demonstration, let’s oversimplify the source code to the most basic elements of a generic storefront, and add “contenteditable” attributes to make all <div> focusable:

original source code order for code pen example
Image shows original and well-organized source code order for the CodePen example

Now let’s also pretend the design has had many revisions. That’s how the code ultimately ended up in the above order. Because developers told designers: “Ok, go crazy folks! Devs can reorder it, we have CSS grid powers” (not that this happens in real life). So, we get this visual order:

change in tabbing order animation
Animated GIF shows how CSS grid visually changes the order of the elements and its tabbing order

Link to the CodePen Example

The above is nowhere near close to the source order. For users without disabilities, there’s nothing wrong with this picture since everything is a mouse-click away, no big deal. But now let’s empathize with a couple of UX personas with disabilities to see how they experience the user journey.

  • John: blind user, uses keyboard-only navigation. He relies on a screen reader vocalization to know where he’s at, and to get to the next element in a UI.
    For John, reaching the search bar, navigation and product has priority. Let’s not forget he can’t see which element comes next. This is a storefront, so let’s not delay him from checking out the product he’s looking for.
  • Jane: right-handed user. Recently broke her right arm. Has to use keyboard-only navigation. Relies on her sight to know where she’s at, and for getting to the next element in a UI.
    Although Jane’s disability is temporary, and she can see which element comes next… oh wait! not quite. For her, all this jumping around the page is very annoying. She gives up and heads to the competitor’s storefront.

In conclusion

If you must use CSS grid in a project that targets Web Accessibility. My first suggestion would be to follow Inclusive Design Principles while designing the UX, the UI and while coding it. This will help reduce visual versus logical reordering scenarios. It’s important to realize your UX personas different situations and their context.

Other suggestions to improve Web Accessibility

  • Start with a structured and accessible document, something that makes sense even without CSS.
  • Spot key elements that, when vocalized with a Screen Reader, make sense to the user journey.
  • Avoid reordering the visual order of the aforementioned key elements.
  • Limit the use of CSS grid to layout the structural areas (ex. header, aside, footer, main, etc.).
  • Avoid using CSS grid inside the structural areas to reorder elements within (like in the demo), but if you really must do this, check for Accessibility at every step. Revisit the Inclusive Design Principles, cases vary, but chances are more empathy is needed.
  • Always come back to the source and check if the order still makes sense when aligned with the visual order.

Beginning and finishing with a well-structured document is the best way to start achieving Web Accessibility. Remember text in the document is the spoken representation of the website. Meaning, the order in which the elements on the UI will be vocalized. By screen reader software, and most likely by any other assistive technology. The un-styled document should always make sense when read by humans and by assistive technologies.

I know, wouldn’t it be great if browsers had a way of figuring out and following the visual order in a page instead of the source order? #Futurism?