Reading Time: 3minutesA man holding a credit card while typing on a laptop.
If you are the owner of an online storefront in Canada, you should get familiar with Screen Reader software and start listening to your website. In August 2022, the Retail Council of Canada published the Accessibility Amid a Changing Retail Landscape Guidebook to provide Canadian retailers with quick tips on how to interact with customers with disabilities. Out of its 28 pages, 18 emphasize in-person interactions, and only five pages are about online interactions, mostly WCAG references.
Making online stores accessible has become a trend in Canada. The Government of Ontario is targeting the creation of an accessible province by 2025 through the Accessibility for Ontarians with Disabilities Act (AODA). Other provinces are following along and the Federal Government has also started moving toward federal regulation by creating technical committees. The consequences of non-compliance for the Web Accessibility part are still unknown, but if we look at how it’s going in the US with the ADA, there are some reasons for concern.
I will not get into details about WCAG (the technical standard) because it’s where people stop reading and start stressing. Rather I will try to convey what the expectation is for an accessible online storefront. In my experience as a Certified Professional in Web Accessibility, I recommend starting with making Screen Readers work well on storefronts, instead of starting with colour contrast and font size.
There is a layer on every User Interface (UI) that “speaks” to the user, literally. If it doesn’t, then something is wrong. In this context: silence is bad. If you test your storefront with a Screen Reader and don’t hear anything, or the vocalization doesn’t match the part of the page you are on, most likely your storefront is not accessible, therefore not compliant.
Web Accessibility is hard to implement because it’s hard to empathize with what the User Experience (UX) should “look like” for people with disabilities. In my experience, once it’s understood that we must aim instead for what it should “sounds like”, then we will be closer to fixing the problem from the ground up. Think of it as a person telling you over the phone what they are doing while shopping at a supermarket. This “listening experience” should match the user’s interactions.
Nowadays, most people know what wheelchair ramps are for in supermarkets. Most shoppers, handicapped or not, find it useful to push that big button to automatically open the doors. Audio jacks have been available in ATMs for over 20 years. All the previous allow consumers with disabilities to exercise their full shopping potential in the physical world. It doesn’t have to be any different for online shopping.
Also, there isn’t any lack of examples of what an accessible UX sounds like, we just need to know where to look. For instance, if we keep in mind that Government Organizations should be compliant with Web Accessibility as well, my first reaction would be to take a look at how “Retail by Government” is being implemented, so the online storefront of the Liquor Control Board of Ontario (LCBO) would be my first stop in finding out.
I’m not saying you should follow LCBO’s UX “by the numbers”, but listening to its vocalization while browsing it with a Screen Reader, will give you a better idea of what the goal is.
If you manage to make your online storefront vocalize accurately, the rest of the accessibility bugs are discoverable with automated testing and fixes are easy. Yes, you still need developers and accessibility experts, and no, widgets and overlays will not provide compliance.
This Accessibility Advocate Checklist is a compass. A non-thorough and non-technical Accessibility checklist for the person taking the role of Accessibility Advocate in a development team. All steps in this checklist lead to knowledge discovery for the Advocate as well as for team members.
Identify
Critical user journeys.
Testing cases and QA scenarios for Accessibility
Verify
All User Interface components have Keyboard Accessible Patterns.
User journeys are doable using only the keyboard.
Keyboard traps do not interrupt or prevent user journeys from being successful.
User journeys vocalize properly using a Screen Reader with keyboard navigation.
If the project is for government employees in a regulated environment.
Reading Time: 3minutesTeam of 5 people seated at a conference table examining a User Interface on a monitor.
A Web Accessibility Advocate, in the context of Software Development, is the team member in charge of raising awareness and increasing the Web Accessibility literacy of the team. Also ensuring that knowledge stays in the team.
Among the responsibilities of a Web Accessibility Advocate are the following:
Raise awareness of potential consequences of non-compliance.
Run the Accessibility Advocate Checklist for all team’s projects.
Provide accessibility questions for interviewing job candidates.
There are similar “advocacy” roles in software development teams. Such as the “UX Advocate” role, following along the lines of the User Advocacy principle. These advocacy roles become handy especially when the Designers’ ratio in development teams is very low. Also, when designers are temporary contractors. Once delivering wires and visuals, they leave. Hence, the need for a developer, who also has “that” UX awareness, to take on that role.
All that said, the same principle applies to Web Accessibility. Consequently, any team member can take on the role of Accessibility Advocate. However, coding practices covered in the topic are better communicated from one developer to another. It’s best if a developer takes on that role. Still, it could be anybody.
When taking on the Web Accessibility Advocate role, the huge body of knowledge should not be intimidating. There is no need to understand it deeply when starting, not even the empathy part. There are tools and tricks to learn how to empathize. However, the reasons for taking the role should be clear and convincing. Not just because it’s fancy-sounding or a trend.
Why it’s important
First of all, is important to understand why Web Accessibility is important in software? besides the fact that it’s the right thing to do. The web has the potential to bring an unprecedented level of independence to people with disabilities. For them Web Accessibility is freedom. As IT professionals, one has the great opportunity to enable this independence for people with disabilities and improve their lives.
People with disabilities can’t easily leave their houses They may encounter barriers outside their homes. But they can perform tasks from their computers like working, shopping, banking. Even have access to entertainment or playing games online. But that’s only if the websites or the software are built with accessibility in mind.
There’s a different approach to Accessibility, that also renders results. By not worrying about being “nice” for a moment, and just focusing on being “smart”. Then embracing Web Accessibility to “show-off”, protect or build a brand. Most likely competitors are also doing their part in complying with Web Accessibility.
Plus, a clear benefit of building inclusive software is that it often results in a larger user base. Yes, more clients, due to the positive impact on more people’s lives.
Now, if the previous “nice” or “smart” reasons aren’t good enough to convince. Then, the “litigation avoidance” reason should prevail. Lawsuits for non-compliance are very common these days. Litigation is the most expensive way to implement accessibility.
All the previous goes to show, that being a Web Accessibility Advocate is a way of being proactive. By anticipating and preventing lawsuits for software companies and their clients.
How to start
Every process is different, niches vary, teams have their own personalities. In my experience, I have found that answering the following questions helps in shaping up the Advocate role. Also, they help to outline an Accessibility Roadmap.
Who is the person that will take the role of Accessibility Advocate?
Is our product static and likely to have flawless and durable 100% Accessible status?
If our product evolves, when are regressions likely to happen?
How do we “painlessly” dive into Accessibility Requirements to anticipate and reduce legal problems?
How do we recognize the pitfalls to avoid?
Accessibility is a practice, not a one-time project. So how do we know where to start and where to end the cycle?
How do we know when we have arrived, or how much is left?
Do we start from scratch or retrofit?
Where will we build ourAccessibility Resource Centre? (Virtual space where we can pour in statistics, tips and tricks, references and painless approaches concerning Accessibility for our product).
Reading Time: 3minutesThe image shows two women conducting a job interview with a male candidate in an office with a city view.
As I wrote in a previous article, Web Accessibility Jobs are on the rise. This inevitably points to a job interview. It would be of great help if people involved in the recruitment process added some Web Accessibility questions to the interview. Especially for non-expert positions. That way, word will spread that this is something the hiring company values in candidates.
In my experience candidates will at least read about it later if they miss answering during the interview. Depending on the position, sometimes the hiring happens, sometimes it doesn’t, but the “Accessibility Seed” will be planted in that person’s mind. Using that “seed” analogy, let’s apply that to the questions.
5 Seed Questions for Interviews
Now, what are good questions to ask in order to assess the candidate’s knowledge about Web Accessibility? Short and sweet, if we are NOT hiring an “Accessibility Expert”. In my experience, these open-ended questions will have answers like “no”, or detailed descriptions. Also, they will leave candidates thinking, even if they don’t know the answer:
Do you know what Skip Links are? … if yes, elaborate.
Do you know what a Screen Reader is? … if yes, elaborate.
Do you know what the Accessibility Tree is? … if yes, elaborate.
Are you familiar with ARIA? … if yes, elaborate.
Are you familiar with WCAG? … if yes, elaborate.
Explanation: If candidates don’t know what Skip Links are, they are most likely not familiar with Keyboard Navigation, which in turn is a must for Screen Readers, which happens to vocalize the Accessibility Tree, there where we use ARIA to fix issues related to it. Mentioning WCAG just makes sure the candidate has never heard of Web Accessibility before. That, if the four previous were negative answers.
All 5 are easy to remember by candidates: Skip Links, Screen Reader, Accessibility Tree, ARIA, WCAG. All 5 are great entry points for research and personal improvement. They all dive deeper into knowledge areas shared by Designers, Developers, Product Owners, Managers and Testers. Even without them knowing.
It really depends on the position we’re hiring for. Questions will not be the same when hiring for a Web Accessibility Engineer/Specialist, or when hiring for a Frontend Developer, a Tester or an Intern.
Interview Questions for Experts
A quick search on Google for “web accessibility interview questions” will result in some of the links listed at the end, which are very good and detailed, but in my opinion, not all the questions apply to just any candidate. They all seem to be addressed to hiring either Web Accessibility Testers or Web Accessibility Engineers or Specialists.
Yes, it would be great if all candidates knew all those answers. But honestly, unless we are hiring experts most people don’t know, and they are not to blame. Web Accessibility is not new. Browsers, software, and laws that support it have been around for decades. What is new, is that the number of lawsuits became alarming around 2017 in the US. These days, it is a must-have for websites in North America with other regions following along. So, realistically, this is still new for way too many people.
Now, for non-expert positions. Candidates failing to answer any of the previous 5 seed questions should NOT prevent the hiring of candidates if they shine in other areas. Web Accessibility can be learned without having to know the theory. Also, there’s no better way to start understanding it than to power up a Screen Reader, start browsing and stop for silent elements.
Nonetheless, this is interesting and precious information to have handy. So, I’ll leave them here and come back to this list as I find more resources on the Job Interview topic:
Reading Time: 2minutesThe image shows a shared open office space with many people working at workstations with big monitors.
When I finished writing the article about the Web Accessibility Engineer, I started to keep track of the links I posted there. Consequently, I noticed the information linked in there seemed to evolve over time. Hence, my curiosity led me to dig deeper into what other Web Accessibility Jobs could be found, or trending, for a Web Accessibility Professional. There are quite a bunch, and certainly on the rise.
This is great, it makes me very happy for newcomers and the new generation of professionals who join the Web Accessibility domain. For the most part, this work domain used to be a very lonely occupation before the year 2015. Or at least it was for me. That is to say, very few people could play along when implementing Web Accessibility.
To share the joy and for those who are interested, I will list and update my findings of Web Accessibility Jobs in this post. In addition to this, if you stumbled upon this post by chance and have a search string you want to share. Please do so in the comments. Do not post individual job positions. Only search strings.
Reading Time: 4minutesThe image shows a female software engineer wearing headphones and writing code on a laptop connected to dual monitors.
In short: a Web Accessibility Engineer is the person ensuring web technology is released accessible by removing the barriers that may prevent equal access for users of assistive technologies. This definition is almost the same as that of a Web Accessibility Specialist. So, how did this come to be?
In the beginning
Since around 2017, a vicious practice known as Predatory Litigation became a trend in the Web Accessibility domain in the United States. It consists of sending letters to companies, threatening legal action, or even filing suits. Alleging their websites are not in compliance with the ADA (Americans with Disabilities Act). Even when that law does not literally address Web Accessibility. Only places of public accommodation are mandated as accessible by the ADA Title III.
But once in court, it becomes a matter of law interpretation. This is scary for companies. Rulings over time have been consistently clear. Saying websites are an extension of a business, which are places of public accommodation. Therefore websites should be accessible. This phenomenon of “serial lawsuits” has caused federal accessibility lawsuits to exceed the 2,000 suits mark by 2018, and growing.
Most of the time companies don’t know the accessibility level of their websites, so they settle. Although the recommendation is not to settle. Mainly, if a website is already somewhat accessible, and being improved on what is missing.
Now, thinking that just because software is not public-facing things will be “OK” with accessibility is not accurate. Employees can sue too.
In the US if a company has more than 15 people, then employees can sue based on the ADA. Especially if the company recruits candidates with disabilities. If the users happen to be Federal Government employees, then it’s even stricter. Employees can sue based on ADA and also under Section508. The government knows this, so they will avoid buying non-compliant software.
Litigation is the most expensive way to implement accessibility. Therefore, companies have started to recruit more candidates with Web Accessibility knowledge. Since 2018 a new role has started to emerge in job listings: Web Accessibility Engineer (WAG).
Before the WAG, there used to be the Web Accessibility Specialist (WAS). Very present in job listings too. Not to be confused with the IAAP WAS certification. It has the same name. The purpose of that credential is to validate the knowledge and skills required by the job role with the same name.
Now, by looking at the job description of both WAG and WAS I see many similarities. The only difference is that the WAG has more hands-on coding skills requirements. JavaScript (JS) for most cases. The salary also reflects this. Going from 10 to 40% more for the WAG according to internet pay scale sources. This varies by country and region. Here’s a quick glance:
In some of those salary links, it’s revealing to see under the WAG description that there are not enough reports to show salary distribution. I assume it’s still a very new job role as of 2019. Also, I see that WAG overlaps with the Accessibility Developer role. An interesting detail.
Usual Requirements
Regardless of years of experience. Removing the soft skills any professional should have. As well as the candidate’s good-to-haves, those change from one company to another. Removing all that, most job postings on the internet include the following as common qualifications for a Web Accessibility Engineer:
Experience with Accessibility Evaluation Tools.
Perform accessibility audits of web pages, desktop applications, and mobile apps.
Experience with Assistive Technologies across multiple platforms. Including Screen Readers, Magnification, and Read-aloud tools (e.g., VoiceOver, NVDA, JAWS, ZoomText, Dragon Naturally Speaking).
Experience with Mobile Screen Readers using gestures.
Write reports describing accessibility issues and recommendations for resolving them.
Knowledge of Document Accessibility Remediation (e.g., Word, PDF, PowerPoint, Excel).
Provide Quality Assurance feedback.
Rapid prototyping to evaluate potential technical solutions.
Solid knowledge of WCAG Success Criteria.
Solid knowledge of WCAG Techniques and Failures.
Knowledge of Accessibility compliance for ADA, Section508, CVAA-255, ACAA, EN 301 549 and Regulatory Environments.
Understanding of the difference between Legal Compliance vs Accessibility Beyond Compliance.
Answer accessibility-related questions, through helpdesk tickets and calls.
Train new hires and clients in accessibility standards.
Proficient with HTML, CSS and WAI-ARIA.
Proficient with JavaScript or an Object-oriented language (Seems a must-have, for most Web Accessibility Engineer’s job postings as opposed to Web Accessibility Specialist’s postings).
At least one Accessibility Certification: CPACC, WAS, 508TT, CPWA (mostly optional).
Experience working directly with disability communities (mostly optional).
Knowledge of User Requirements for people with disabilities.
Understanding of the difference between Accessible Design vs Inclusive Design.
The Bottom Line
In conclusion, a Web Accessibility Engineer is a Web Accessibility Specialist who is also a Web Developer.
I remember the same thing happened with Frontend Developers. There were many role names for people who only knew HTML, CSS and jQuery. They were called UI Developers, Integrators, etc. They complemented PHP and Java workflows. That, was before JS became a full-fledged language. Then JS was a requirement, and the Frontend Developer role was coined. Then backend knowledge was added to the mix, and the Full-stack Developer role was born.
In my opinion, the same thing will happen with Web Accessibility jobs. They will start to change and adapt to the workflow. Job roles and requirements will evolve over time.
Reading Time: 8minutesAn 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:
The main goal of a storefront is to allow users to checkout products.
Elements on the interface should facilitate the user to complete checkout, including users with disabilities.
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.
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.
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
We can validate Storefront Accessibility by “walking the walk” with empathy.
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.
A web developer should make sure an accessible critical user journey actually works before handing it over to the QA tester.
The best validation tool is empathy.
Sometimes by closing our eyes, we can “see” where the problem is.
Shoppers with disabilities should be able to purchase online as they do in brick-and-mortar stores.
Nobody is exempt from disabilities through a lifetime, best case scenario: we all age.
Web Accessibility should be seen as a business opportunity in any lead-to-cash strategy before it becomes a lead-to-lawsuit scenario.
