For me—and for more than a billion people worldwide living with disabilities—accessibility isn’t a feature, enhancement, or a “nice to have.” It can be the difference between independence and exclusion. 

I strongly believe most people understand the importance of access to digital information.  
I also believe most people care about creating digital experiences that enable every user to accomplish what they set out to accomplish.  
 
However, the reality is—many organizations don’t believe they have the resources to prioritize accessibility, so they delay or deprioritize it entirely.  

As someone who’s blind, this is frustrating. But as someone who’s been in the accessibility industry for more than a decade, delaying or deprioritizing accessibility is a costly, brand-damaging decision—now more than ever.  

Why Accessibility Now? 

Before getting into the risks, let’s talk about what’s driving accessibility urgency. 

At the core, what we continue to hear is that legal rulings and rulemaking predominantly drive urgency. As background, here are a few laws—and deadlines to be aware of:  

ADA Title II

The U.S. Department of Justice issued final rulemaking in 2024 clarifying that U.S. state and local government agencies, including their vendors and contractors, must ensure their websites, apps, embedded products, and conventional electronic documents conform with WCAG 2.1 AA standards. The deadlines for compliance are April 2026 and April 2027—depending on a municipality’s population size.  

This is particularly important because the ADA was written into law before the prevalence of digital content. Clarifying that Title II of the ADA applies to digital content is a huge step forward for access and holds local and state agencies clearly accountable.  

However, if you’re not a public sector agency and think you’re in the clear, you might not be. If you do any business with a Title II entity, the rule likely applies to you as well. Sales to the public sector, whether new business or existing contracts, are now at risk if your products and services are not accessible. 

ADA Title III

Title III of the ADA is applicable to the private sector. It states that “places of public accommodation” must be accessible. Whether public accommodation applies to websites, mobile apps, and other digital experiences, has largely been up to interpretation. This means that if a user encounters an access issue, they can sue that business. And they have—by the thousands every year. And in many cases, ADA lawsuits are filed under the banner of state-level laws, such as the California Unruh Civil Rights Act, compounding the costs.  

Importantly, the number of ADA-related lawsuits targeting websites and mobile apps is already outpacing the number of lawsuits filed in all of 2024, and we have months yet to go. And this number doesn’t account for the number of demand letters, which do not enter the public record. The legal threat is not going away.  

Section 508 of the Rehabilitation Act of 1973

U.S. federal agencies—and their vendors—must deliver, and procure, accessible information and communications technology. Since Section 508 was refreshed in 2018 to incorporate the Web Content Accessibility Guidelines 2.0, it explicitly includes web sites, mobile apps, and documents. This law has been around for years, but I bring it up because—similar to Title II—it doesn’t just apply if you’re in the public sector. If you want to do business, or keep doing business, with the federal government, what you sell must be accessible.    

European Accessibility Act (EAA)

As of June 28 of 2025, the EAA requires the accessibility of digital products and services. But this isn’t just a regulation impacting our friends across the pond. What you may not know is that if you have any customers who are based in the European Union—regardless of where your organization is located—the EAA applies to your business. The consequences of non-compliance, such as damages, fines, and penalties, vary depending on each EU member state. 

State-Level Requirements

Certain U.S. states are doubling down on access to digital communications, many replicating the same timelines and approach required in the recent Title II rulemaking. Colorado and Virginia are establishing statewide accessibility standards related to software and digital product procurement. Colorado’s standard goes as far as stating the “contractor shall indemnify the State agency in relation to the contractor’s noncompliance with the accessibility standards.” 

Sell to an organization in Colorado or Virginia—and accessibility is a must.  

Bottom line, compliance requirements are clear—becoming clearer—and they’re not going away. Quite the opposite, in fact. New laws, requirements, and standards are coming online from all corners of the world.

The Dangerous “Delay and Risk” Mentality. 

This brings us to the dangers of delaying or deprioritizing accessibility. Even as compliance deadlines loom, we continue to hear teams say, “We’ll take the risk.” 

I understand the temptation. Budgets are tight. Competing priorities can feel more urgent. Lawsuits may seem like someone else’s problem. But from where I sit, this mindset is a gamble with very real stakes: 

Legal risk

Settling a lawsuit is costly and doesn’t make the problem go away. If your organization is sued or served a demand letter, you still have to fix the problem. Now you’re on the hook for potential legal or settlement fees, and settling one ADA lawsuit does not prevent you from receiving another from a different plaintiff. On top of any legal or settlement costs, you now have to pull together a reactive accessibility plan—which suddenly consumes unplanned, valuable time and resources.  

Lost revenue

Delays or deprioritizing can cost money on several fronts: 

• If your organization is sued, retroactive fixes are far more costly than proactive design. Plus, you’re likely paying legal or settlement fees on top, as addressed earlier. But also think about the financial impact to your workflows or your product roadmap. Legal settlement agreements often hold organizations to a 12-month timeline, so you’ve now forfeited your development roadmap and potentially delayed your new product releases. Ready to take that financial risk?   
• Your buyers’ procurement teams require VPATs/ACRs, which document a software or digital product’s state of accessibility. Lack of accessibility often means no new contract. It can also mean no renewal with existing customers who are prioritizing accessibility.  

Brand damage

Inaccessible experiences go viral quickly. Don’t take this lightly. Lawsuits are also often a matter of public record. And consumers are loyal to businesses that share their same values—access and inclusion among them. If you’re an e-commerce or retail organization, this point is particularly important. The vast majority of ADA-related lawsuits target e-commerce. 

Access denied

When organizations “wait and see,” they aren’t just risking lawsuits—they’re actively excluding a large subset of users. Accessibility delayed is access denied.

It Pays to Act Now. 

Accessibility takes time, especially at enterprise scale. Organizations managing thousands of web pages on hundreds of sites, multiple web or mobile applications, and vast libraries of documents can’t just “flip a switch” a few weeks or even months before a deadline. 

Prioritizing accessibility now gives you the ability to: 

• Work accessibility into your creation roadmap (websites, apps, products, PDFs, etc.) instead of retrofitting later. 

• Allocate sustained investment and spread resources out over time to ultimately reduce long-term costs. 

• Gain competitive advantage in contracts and RFPs. 

• Build trust and loyalty with customers, partners, and employees. 

Allyant is Here to Help. 

Accessibility is more than compliance—it’s a business imperative. From my experience, organizations that treat accessibility as an afterthought rarely win long term. So when I hear, “We’ll take the risk,” I can’t help but think: risk for whom? For your organization, its reputation and its lost revenue? Or for people like me, who will experience another closed digital door?  

The deadlines are coming.  
The risks are growing.  
The time to act is now. And Allyant is here to help. 

If you’d like to understand what accessibility readiness looks like for your organization, including both short and long-term wins, connect with our team today.  

The post Why Accessibility Matters—And Why It Matters Now  first appeared on Allyant.

In this blog post we dig more deeply into what this guidance means, what it does not mean, and why it is needed for mobile app designers and developers.

What This Guidance Is

Applying WCAG 2.2 to Mobile Applications offers informative (non-normative) guidance on how WCAG 2.2 principles, guidelines, and success criteria can be applied to mobile applications, including native mobile apps, mobile web apps, and hybrid apps using web components inside native mobile apps.

Key highlights include:

• Comprehensive Coverage of WCAG 2.2 Success Criteria: The guidance addresses the Level A and AA success criterion from WCAG 2.2 which are applicable to mobile applications, providing context-specific guidance for each. This includes considerations for touch interactions, screen orientation, and mobile-specific user interface elements. 
• Interpretation of Web Terminology in Mobile Context: Recognizing that certain web terminologies may not directly translate to mobile environments, this guidance helps bridge the gap between web-based terminology used in WCAG (e.g., “web page,” “set of web pages”) and the structure of mobile applications (e.g., screens, views, dialogs) to ensure clarity and relevance. For instance, it reinterprets the concept of a “web page” to align with elements commonly found in mobile apps, such as screens or views. This ensures that developers can accurately apply accessibility guidelines within the unique constraints and capabilities of mobile platforms.

What This Guidance Is Not

It’s important to note that this document:

• Does not introduce new success criteria or propose changes to WCAG 2 or its supporting documents.
• Does not provide sufficient techniques or code examples for implementing WCAG 2 in mobile technologies.
• Should not be considered a standard. This document is purely an informative note about mobile applications, not a standard, so it does not describe how mobile applications should conform to it.

Why This Guidance Is Needed

Although WCAG was originally developed for web content, it has become the de facto standard for mobile accessibility as well. WCAG is referenced in numerous laws, regulations, and legal decisions worldwide, including the European Accessibility Act (EAA), Sections 504 and 508 in the U.S., and others.

However, applying web-based criteria to native mobile experiences has led to inconsistencies, confusion, and even conflict.

For professionals involved in mobile app development, this new W3C guidance aims to reduce that friction by offering a clearer, shared understanding of how WCAG 2.2 can be interpreted in mobile environments.

By integrating the guidance into the design and development lifecycle, teams can proactively address potential accessibility barriers, leading to more inclusive, user-friendly, legally compliant mobile applications.

Our Perspective

At Allyant, we believe the guidance in Applying WCAG 2.2 to Mobile Applications is a meaningful step forward in helping organizations meet their mobile accessibility obligations. It provides a much-needed foundation for greater clarity and consistency.

We welcome this progress and look forward to further developments from the W3C Mobile Accessibility Task Force, which continues to explore how accessibility guidance can better reflect the needs of mobile users and developers alike.

And if you’d like any support with mobile app accessibility—whether auditing an existing app or expert review of your designs or wireframes, we’re ready to help. Engage our team today.

The post Applying WCAG 2.2 to Mobile Apps: What the New W3C Guidance Means for Accessibility first appeared on Allyant.

As someone who is blind, I’ve always had mixed feelings about traveling. While I eagerly anticipate the food, weather, and meeting new people, one of the main attractions of vacationing—sightseeing—isn’t something I can fully experience like a sighted person.

To make the most of our trip, we planned activities, locations, and experiences that I could enjoy more fully.

In this article, I’ll highlight some of the accessibility successes and challenges I encountered during our trip.

Traveling with a Guide Dog

To ensure we didn’t encounter any issues bringing my guide dog, Jeb, across the U.S./Canadian border, we contacted Guide Dogs for the Blind (GDB), the organization that trained Jeb.

GDB offers client support services, including travel assistance, to help identify any legal requirements for traveling internationally with a guide dog. They recommended I have the following:

• Jeb’s official paperwork from GDB, identifying him as a graduated and active service dog.
• Vaccination records from Jeb’s vet, particularly his rabies vaccination status.
• A completed CDC Dog Import Form and receipt.

Overall, the process went smoothly. GDB emailed a PDF of Jeb’s paperwork, which I could print, and Jeb’s vet also sent a PDF of his vaccination records. Once I had the vaccination records, the CDC Dog Import Form was relatively quick and easy to fill out.

With all the necessary documents in hand, we headed for the border, where… we weren’t asked for any of it. Ironically, if I hadn’t had all this paperwork ready, we likely would have been asked to present it.

GuideAlong

My partner Sybil heard about an app that provides audio tours based on your phone’s GPS location, but she wasn’t sure what it was called or where to find it. Thankfully, we live in the age of ChatGPT and Microsoft Copilot.

I asked Copilot for a list of apps that offer audio tours based on GPS location, and GuideAlong was at the top of the list. This app completely transformed my experience on the trip, allowing me to enjoy the sights and scenery in a way that was much more accessible to me as a blind individual.

The GuideAlong app offers in-app purchases of various tours at many different parks and locations, not just Banff. For our trip, I purchased two tours: one for Lake Louise, Emerald Lake, and the surrounding area, and another for Banff town proper.

We connected my phone to our car’s Bluetooth, and as we traveled, everyone in the car got to listen and experience the audio tour. We heard some amazing stories, including the construction of the Spiral Tunnels and how the Banff Springs Hotel was initially built facing the wrong direction.

The two tours provided hundreds of announcements along their routes, and we heard the vast majority as we traveled to each of our destinations.

It was a fantastic way for me to immerse myself in the surroundings without feeling like a burden by asking others to describe the scenery, and we all enjoyed hearing some fascinating stories.

Takakkaw Falls

One of the unexpected highlights of our trip was definitely Takakkaw Falls. It wasn’t on our original itinerary, but as we traveled from our Airbnb in Golden to Banff, the Guide Along app mentioned Takakkaw Falls, one of the largest waterfalls in Canada, and described how truly amazing it is.

While I couldn’t see the waterfall, a walkway leads nearly to the base of the falls, where you can hear the roaring water, feel the pressure of its powerful flow, and sense the cool mist in the air. The sound and feel of the falls helped me understand and appreciate its immense size and scope.

Another unexpected bonus when visiting Takakkaw Falls was discovering an amazing onsite 3-D model. This model shows the falls, the glacier that feeds it, and the surrounding area.

We came across it while walking back to our vehicle, and it was an unexpected delight. It was incredibly informative, allowing me to feel and understand the layout of the land and grasp the immense size of the glacier feeding Takakkaw Falls.

Buffalo Nations Museum & BeMyAI

While the Buffalo Nations Museum in Banff didn’t advertise or offer any accessibility services for the blind, it was still an engaging experience for me, thanks to BeMyAI.

As my partner Sybil and I moved from one exhibit to another, she snapped photos of the exhibits (with the museum’s permission) using her phone’s camera app. She then sent me the photos, which I quickly ran through BeMyAI.

Although the process was a bit clunky, and not all descriptions were perfectly accurate, it allowed me to enjoy the experience. I especially appreciated being able to sit down afterward and go through the photos at my leisure.

The photo above was actually the first one Sybil took, and it generated the most amazing description using BeMyAI. If you’re curious, check out the alt text on the image above, which is almost the exact text generated by BeMyAI for this exhibit.

Banff Park Museum

When planning our trip, we researched museums and other sites with accessibility services. Like most folks in 2024, we relied on a combination of recommendations from friends, family, and coworkers, Google searches, and AI tools like Microsoft Copilot.

Based on this research, we believed that the Banff Park Museum offered accessibility services for both the hearing and visually impaired. Unfortunately, when we arrived, the staff were unaware of any accessibility services for individuals who are blind or have low vision.

As a consolation, the staff did not charge me for admission. I used BeMyAI to describe some of the exhibits, though most were simply of local wildlife. Being from Montana, where wildlife is abundant, I didn’t feel as compelled to photograph and describe each exhibit.

Cave and Basin

Cave and Basin was definitely on our itinerary, as its website listed numerous accessibility services and even mentioned that guides were available, which seemed like a great way for someone who is blind to experience the site.

Unfortunately, I wasn’t the only person in our group with a disability—one of our group members has a motor disability that makes walking long distances quite difficult.

When we arrived at Cave and Basin,we realized that they weren’t comfortable proceeding with the amount of walking involved. Rather than leave anyone out, we decided to spend the time driving around and listening to more of the Banff Town Tour on the Guide Along app—something we could all enjoy together.

Conclusion

Our journey to Banff National Forest highlighted how accessibility can significantly enhance or hinder the travel experience for individuals with disabilities.

While we encountered some challenges, such as the lack of advertised accessibility services at certain sites, we also discovered unexpected delights like the 3-D model at Takakkaw Falls, audio tours using Guide Along, and the invaluable assistance of BeMyAI.

Our trip was a testament to the importance of thorough planning and the willingness to adapt when things don’t go as expected. Despite the obstacles, the beauty of Banff and the shared experiences with my family made the journey truly memorable.

I hope our experiences inspire others to explore and advocate for more accessible travel options, ensuring that everyone can enjoy the wonders of the world.

The post Banff Bound: A Somewhat Accessible Journey first appeared on Allyant.

My experience may not be the same as other blind / low-vision users, and will certainly be different from the experience persons with other disabilities, such as motor/dexterity or cognitive disabilities, may have as they try to access the web.  

When accessing the web, I primarily do so using the following devices and assistive technologies: 

• A Dell XPS 13 laptop running Windows 11 w/JAWS for Windows as the primary screen reader 
• An iPhone 13 Pro Max running iOS 17 w/VoiceOver as the primary screen reader.  

In this article, we’ll talk about what it is like to access websites and applications using the first device I mentioned above – a desktop/laptop computer running Windows and using the JAWS screen reader.   

What does a screen reader sound like? 

For those who have never heard a screen reader in action, it can be an illuminating experience. 

Below is a paragraph of text from the Allyant website, and following that is a short clip of this text being read out by my screen reader. Keep in mind that this is how my screen reader sounds when browsing websites, reading emails, etc., but this is only 60-65% of the maximum speed supported by my screen reader.  

“At Allyant, we believe every organization’s journey toward equitable access should be simple and seamless—eliminating the worry, stress, and uncertainty often associated with accessibility. For this reason, we offer many accessibility services and software solutions, spanning print and digital document remediation services, document remediation software, and digital accessibility auditing.” 

Screen Reader demo

What do I mean by “Web Applications”?

For the purposes of this article, the term “web applications” refers to complex web apps that you interact with from within the web browser and which override the traditional keyboard behavior found on a conventional website. Examples of popular “web applications” include Google Docs, Google Sheets, Microsoft365 Web Apps, Slack, and many, many more. 

In some cases, a website/service may fall between a conventional website and a full-on web application. For example, Twitter/X has keyboard shortcuts available for many functions but doesn’t generally override keyboard behavior and take control like a typical web application does. Other examples of this include YouTube, Vimeo, and other services that provide some limited keyboard-specific shortcuts within an overall web page.       

Keyboard Shortcuts on the internet

In my previous article on navigating websites as a blind user of screen-reading software, I mentioned how important landmarks, headings, and other structural elements are to effectively navigate a site using a screen reader. The trick is that most of these keyboard shortcuts are unavailable to screen reader users when navigating a web application. 

When a web page is opened using screen reading software, the screen reader essentially creates its own “virtual” version of the web page based on the contents of the accessibility tree. What the user is hearing and largely moving through is this “virtual” version.

This enables the screen reading software to control the navigation and to intercept all keyboard shortcuts that the user enters.

The result is that when a user presses the H key, they move between headings; when they press the L key, they can jump to lists, and so on. 

Keyboard Shortcuts on Web Applications

With a web application, this is not the case. The web application is responsible for handling all of the keyboard shortcuts rather than the screen reading software. This is essential when you think about it —in order for a user to type in a document in a web application like Google Docs, their keystrokes cannot be intercepted by the screen reading software, so the characters are entered in the document.

For a user to traverse the message history in Slack with the arrow keys, the screen reading software needs to not intercept the up/down arrow keystrokes and try to move focus since Slack will instead move one message at a time through the history.        

Advantages and Disadvantages of Web Applications

When considering whether to approach your tool/service as a web application or instead as a web page, it is useful to think about some of the advantages/disadvantages of this approach to users. 

Advantages

• Specific keyboard shortcuts can be created for a wide variety of tasks.
• More control over how content will be announced to the user.
• Power users who fully utilize available keyboard shortcuts can become highly efficient with the application.

Disadvantages

• The application is responsible for ensuring the user can navigate and access all of the application’s information. This means you must map out how the user will reach every piece of text, every panel, every object, etc.
• The application may appear inaccessible or unusable to novice screen reader users and/or new users.
• Screen reader users, in particular, must learn the application-specific keyboard shortcuts to effectively navigate and use the application. Documentation, and making that documentation easy to find, is critical. 
• Essentially, screen reader users need to forget most everything they know about navigating using their screen reading software, as most screen reader keyboard shortcuts used to traverse web pages will become unavailable. 

Should Developers Avoid Building Services as Web Applications?

Ultimately, there are instances where it is inevitable that a tool/service be designed as a web application. Designing your service as a web application may be necessary to provide all the features/functionality your service requires. 

However, in many cases, it may be possible to provide all of the desired functionality while adhering to traditional web elements and not overriding keyboard focus, as seen in a web application.

For example, tools like the Allyant HUB, Google Search, and many other online tools/services provide significant, complex functionality but do so in a way that utilizes traditional web elements and allows the screen reading software to manage focus no differently than a web page.    

If it is possible to approach your tool/service as a web page instead of a web application, that may flatten the learning curve for visitors to the application.

In particular, for users of screen reading software, who will be able to continue to rely on standard web navigation shortcuts rather than having to learn a new set of application-specific shortcuts.

Approaching your tool/service as a web page rather than a web application will also likely reduce development time and effort since most screen reader and keyboard navigation will continue to be handled by the browser rather than the application. 

What about X/Twitter, YouTube, and other services which are “on the fence”?

The advantage of the approach used for services like X/Twitter, YouTube, etc., is that the user can have the best of both worlds. Keyboard shortcuts are available for keyboard users, and screen reader users can usually treat these just as a web page and use standard screen reader navigation commands. 

The disadvantage is that users of screen reading software may not be able to fully utilize all of the available keyboard shortcuts, or they may need to take an additional step to make the keyboard shortcut work.

As the page has not been marked up as a web application, and the screen reading software remains in its traditional reading mode for web content, keyboard shortcuts will most likely be intercepted by the screen reading software. 

For example, when playing songs on YouTube Music, you can press “K” to jump to the previous song, and by pressing “J,” you jump to the next song. However, if I, as a JAWS user, press “K,” it triggers the JAWS command to jump to the next place marker, and pressing “J” triggers JAWS’ “Jump to line” feature. The screen reader intercepts these keyboard shortcuts, as they are used to help navigate quickly around a web page. 

To resolve this, most screen readers offer a “pass-thru” feature, which essentially tells the screen reading software to allow the next keyboard command to go through to the web browser/page and not to trigger a screen reader-specific command.

On JAWS, this keyboard shortcut is Insert+3. 

Using the example above from YouTube Music, if I want to use the keyboard shortcut “J” to jump to the next song, I first have to press Insert+3, then the letter “J”.

Alternatively, the user can force the screen reader into web applications mode, which allows all keyboard shortcuts to pass-thru until the mode is switched back off.

Unfortunately, these are more advanced features/functionality of screen reading software, and many users may be unfamiliar with how to do this or maybe uncomfortable switching between modes.

Conclusion

Web applications are extremely powerful tools/services and, when designed properly, can be made accessible to users of all abilities.

It is critical when designing a complex web application to consider how screen reader and keyboard users will navigate the application and access various elements.

If it is possible to develop your service and all of its needed functionality without taking full control of keyboard navigation, then that may be preferred as it makes the service easier for visitors to understand without referring to application-specific documentation, and it will also save development resources by not having to implement all the necessary keyboard handling in the application itself. 

If your service must be designed as a web application, it is critical to work with accessibility experts to ensure its features/functionality are accessible, test the application with users with disabilities to ensure it works as expected, provide documentation for users on how to use the application via the keyboard and with screen reading software and make that documentation easy to find. 

The post My Experience of Using Web Applications as a Blind User first appeared on Allyant.

In this article, I would like to highlight three things that were either completely new information to me or that really helped expand my knowledge in a particular area regarding accessibility. 

HECVATs 

One session I attended that I found particularly informative was “Security + A11y: Streamlining Higher Ed Vendor Reviews” during which the Higher Education Community Vendor Assessment Toolkit (HECVAT) was discussed. 

This is not a form of accessibility documentation commonly seen in the industry, certainly when compared to VPATs and ACRs. Still, HECVATs have been gaining interest among accessibility professionals, primarily due to their unique approach of integrating product accessibility questions into the same form vendors use to provide information on data privacy and security. 

An important fact regarding HECVATs, which I was unaware of until this session, is that the HECVAT template is broken into two versions: a “full” version and a “lite” version. Still, both versions contain the same 12 specific questions related to accessibility. If you are, therefore, less interested in the details regarding data privacy and security, and if your primary focus is on the product’s accessibility, then the “lite” version of the HECVAT will work for you.  

For more information on the HECVAT, see the Higher Education Community Vendor Assessment Toolkit on the EDUCAUSE Library. 

Mobile 

Mobile accessibility was a prominent theme during this year’s CSUN conference. My team and I had the opportunity to engage in a wide variety of conversations regarding mobile accessibility and to attend various sessions on the topic. A few sessions in particular that our team found informative and valuable were “From WCAG to MCAG: Towards Mobile Accessibility Guidelines” and “Testing WCAG 2.1.1 Keyboard on Mobile”. A few takeaways regarding mobile include: 

• Everyone in the industry generally seems to agree that WCAG, whether 2.1 or 2.2, is insufficient for native mobile apps. 
• Organizations and experts interpret and apply WCAG requirements differently to mobile apps due to the lack of mobile-specific information and resources in WCAG. 
• In some cases, there is disagreement/contradiction between WCAG, as interpreted by accessibility professionals when applied to mobile, and user interface guidelines provided by Apple and Android operating systems.    
• Two facts that appear to not be in dispute among accessibility professionals regarding mobile: 

1. You must do keyboard testing on mobile, using a physical Bluetooth keyboard and without the screen reader running. 
2. Do not use emulators to test the accessibility of native mobile apps; use actual physical mobile devices instead. 

Microsoft Teams 

While I didn’t get to attend the “Increase Productivity in Microsoft Teams with JAWS” session, several members of my team did and shared some of their notes with me. As someone who is blind and uses screen reading software daily in a work environment that uses Microsoft Teams, the information I learned from this has already changed my life. 

I think it also underscores the importance that first impressions may have on a user, and how difficult it can be to change user behaviors once established.  

Microsoft launched an updated version of Teams last year with a redesigned user interface, and the previous version of Teams was labeled “Classic” Teams. 

When the new Teams first rolled out, I and other users found it didn’t perform well with our screen reading software, and most of us reverted to using the “Classic” Teams as it provided a better experience. After initially testing the new Teams and reverting back to the “Classic” Teams, I never bothered to check again to see how the new Teams might have improved since.  

During the session at CSUN this year, my team saw a demonstration of the new Teams being used with JAWS, and everything performed quite well. On top of that, the team heard about many useful keyboard shortcuts that have been added to the new Teams and are unavailable in the “Classic” version of Teams. 

After hearing about this, I tested out the new Teams myself and found it to perform much more smoothly and the new keyboard shortcuts to be handy. I now use the new Microsoft Teams daily and have moved away from using the “Classic” version of Teams.  

This experience underscores the importance of first impressions regarding accessibility – I and many other screen reader users eagerly tried out the new Teams when it became available, but as it didn’t appear to be accessible or compatible with our screen readers at the time, we switched back to the “Classic” version. Once that happened, there wasn’t much incentive for us to go recheck the new Teams to see if things had changed, and I would probably still be using the “Classic” version if it hadn’t been for this session at CSUN.

The post 3 Things I Learned at CSUN 2024 as a User with Vision Impairment first appeared on Allyant.

My experience may not be the same as other blind / low-vision users, and will certainly be different from the experience persons with other disabilities, such as motor/dexterity or cognitive disabilities, may have as they try to access the Web.  

When accessing the Web, I primarily do so using the following devices and assistive technologies: 

• A Dell XPS 13 laptop running Windows 11 w/JAWS for Windows as the primary screen reader 
• An iPhone 13 Pro Max running iOS 17 w/VoiceOver as the primary screen reader.  

In this article, we’ll talk about what it is like to access websites and applications using the first device I mentioned above – a desktop/laptop computer running Windows and using the JAWS screen reader.   

What does a screen reader sound like? 

For those who have never heard a screen reader in action, it can be an illuminating experience. 

Below is a paragraph of text from the Allyant website, and following that is a short clip of this text being read out by my screen reader. Keep in mind that this is how my screen reader sounds when browsing websites, reading emails, etc., but this is only 60-65% of the maximum speed supported by my screen reader.  

“At Allyant, we believe every organization’s journey toward equitable access should be simple and seamless—eliminating the worry, stress, and uncertainty often associated with accessibility. For this reason, we offer many accessibility services and software solutions, spanning print and digital document remediation services, document remediation software, and digital accessibility auditing.” 

Screen Reader demo

What makes a website bad/inaccessible?  

On one hand, you could say the answer to this is easy – a site that doesn’t conform to the Web Content Accessibility Guidelines. On the other hand, as a user, I have encountered my fair share of sites that might not be WCAG-conformant but were still perfectly usable to me as a user of screen-reading software. 

The opposite can also be true – a site or web application may technically conform to WCAG but be so clunky/non-intuitive as to be functionally unusable to me and other users of screen reading software.   

Speaking just as a user going to a website and trying to access it, there are a few things that will cause me to give up on the site in relatively short order: 

• Lack of useful headings – Headings provide an essential navigational tool for users of screen reading software. Properly marking headings on a page or in a document allows screen reader users to quickly jump to the desired heading/section of the page, similar to how a sighted user may skim through a page looking for big, bold text. It is important to note that what I mean here is when a site doesn’t have any headings or the headings provided are extremely limited. I am not talking about a site that has headings, but the heading levels are in an illogical order, or heading levels are skipped – whether the headings are logical or not, they are useful as a navigation tool as long as they are there. If a site has no headings or limited headings, navigating around each page will be more difficult/time-consuming.  
• Lack of useful landmarks/regions – Landmarks/regions provide a similar function to headings in that they allow users of screen reading software to jump to sections of the page; however, landmarks/regions are usually more broad, such as the site header, footer, main content, navigation, etc. On most sites, decent landmarks/regions are provided by virtue of using good/semantic HTML. If your site doesn’t have good landmarks/regions, then users of screen reading software may find it more difficult/time-consuming to jump back to the site header, or to the main navigation, and so on. While not quite as critical as headings, if a site lacks both headings and landmarks/regions, I will usually close the page and not bother.   
• Accessibility Overlay tools – These tools usually stand out like a sore thumb to users of screen reading software upon reaching a site. Some of these tools will automatically fire off alert messages to inform users of screen reading software that they are present and to prompt the user to enable the overlay functionality. I could write an entire article about overlays in general, but suffice it to say that on most sites, if an overlay is present, it is impossible to ignore the overlay tool. Some overlays will attempt to automatically detect what type of disability you have or assistive technology you use and apply a corresponding “profile.” As someone with a disability, I do not want to have to disclose my disability when I visit online casinos to explore gaming options privately, or apply a disability-specific profile, or use the screen reading/text-to-speech functionality provided by an overlay tool. If a site is accessible, it should just work for me without doing any of that.

If I visit a site and encounter any of these, I usually just close the page and try to find a different site that can serve my needs. 

What makes a website good/accessible? 

Not having any of the above-mentioned issues is a good start. Ensuring your site is WCAG-conformant is always the best way to ensure your site is accessible for all, but as mentioned earlier, just because a site is not WCAG-conformant doesn’t mean it is not usable or that it is inaccessible to me as a user of screen reading software.  

A few things I look for that can give me a quick clue as to whether or not the site is accessible/usable include: 

• Navigation Menus & Site Search – It is surprising the frequency with which I visit a site and find the site’s main navigation menus or the site search is not accessible. If I can’t access the menu to navigate to inner site pages or use the site search to locate products or information, then how can I really use the site? If these gateways to the site are accessible/usable, then that often bodes well for being able to use the site, regardless of whether or not it is fully WCAG conformant.    
• Skip Links & Accessibility Statement – The funny thing is, I, as a user of screen reading software, usually don’t activate/use skip links. My screen reading software provides other tools, such as navigating by heading or landmark, which are often more useful. According to the most recent WebAIM Screen Reader User Survey, I am not alone, as only about 30% of respondents said they either “Always” or “Often” use skip links. However, even though I don’t need to use the skip link, it can be a great barometer of whether the site has accessibility on its radar. This goes doubly so for Accessibility Statements – I don’t usually read them on sites I visit. Still, I do notice when an Accessibility Statement is provided and take it as a good/positive sign when they do.     
• Critical Form Controls – You can spend hours and hours making a site accessible, but if the controls used to select a product size/color option, submit your contact form, or proceed from the cart to the checkout are inaccessible, nothing else really matters. Especially when looking at an e-commerce site or a site where I will be filling out a form, a big question is whether or not those critical controls you will need to interact with are accessible. The most common examples of this I encounter are product size, color, and fit options on e-commerce sites. These controls are very often created using custom HTML elements rather than semantic controls like radio buttons and, as a result, are very often inaccessible. If I can’t select the size and color I want, then it doesn’t matter that you have excellent alternative text on your product images, good heading structure, etc.  

My experience of using Web Applications

Web applications have been gaining popularity in recent years and are slowly replacing traditional desktop-style applications. However, as a user of screen reading software, I have mixed experiences with web applications.

Since web applications are, by their nature, content you interact with from within a web browser, they typically have a higher baseline accessibility compared to desktop applications. I have encountered plenty of desktop applications where I could do nothing, read nothing, interact with nothing, and the application was essentially a blank void as far as my screen reader was concerned. 

However, this doesn’t tend to be the case with web applications – usually, there will be at least some content within the web application that will be perceivable to a screen reader user, even if that is just text.  

As a user, the most challenging part with web applications is often learning how to interact with them, what keyboard shortcuts must be used, etc. 

When navigating a web page, there are standard keyboard shortcuts provided by the screen reading software, for example, pressing H to move by headings, L to move to lists, and commands to read by paragraph, line, word, and so on. 

However, when using a web application, the user has to largely disregard all of their screen reader-specific keyboard shortcuts and instead use shortcuts provided by and specifically for that application. 

For example, to move to the next post on Twitter, you must press the K key; to move to new/unread messages in Slack, you must press Alt+Shift+DownArrow; and to move between panels in Microsoft Teams, you must use Ctrl+F6.  

Learning application-specific keyboard shortcuts can often be frustrating for a screen reader user. I have spent years learning how to operate my screen reader and all of its specific shortcuts, just to have to forget all that and learn the keyboard shortcuts to operate a single, specific application. 

This is one reason why simply providing a keyboard shortcut may not be as good a solution as it may seem – how will users learn about the keyboard shortcuts, how will users keep track of the available keyboard shortcuts, do the keyboard shortcuts interfere with other shortcuts provided by the operating system or common screen readers, do you have the necessary markup to ensure keyboard shortcuts are properly passed from the screen reader to the browser and more. 

Given all this, it is always preferable to go with simple designs using semantic HTML elements, where you can let the screen reader interact with content like a web page instead of forcing it to operate like a web application.     

Conclusion 

Modern screen readers are amazingly powerful tools, and they provide many features and functionality to help users navigate and interact with even the most inaccessible sites. Simply having accessibility conformance issues doesn’t necessarily mean your site is inoperable or unusable, but the best and only real way to ensure WCAG conformance and genuine usability is through live user testing by users with disabilities who use these assistive technologies daily. 

This is even more true when dealing with web applications, as their complex and unique interactions require even more user testing to ensure the application is intuitive and operates as expected when used with a screen reader or other assistive technology. 

By partnering with Allyant, whose audit process is centered on paired auditing with live users with disabilities, you can ensure your websites and applications conform to accessibility standards and are effective and usable to all.

The post My Experience of Navigating the Web as a Blind User first appeared on Allyant.

The World Wide Web Consortium (W3C) has published the latest update to the Web Content Accessibility Guidelines – WCAG 2.1. Building off of the existing guidelines and principles found in WCAG 2.0, WCAG 2.1 adds additional guidance. These new guidelines improve web content accessibility. In addition, there is a specific emphasis on improving accessibility for people with cognitive or learning disabilities, low vision, and disabilities interacting with content on mobile devices. In this blog post, we’ll provide a brief overview of WCAG 2.1 and point out some crucial facts about the changes.

WCAG 2.0 vs. WCAG 2.1

WCAG 2.1 builds upon WCAG 2.0, a significant revision of the original WCAG 1.0 guidelines. WCAG 2.1 extends WCAG 2.0, adding 17 additional success criteria across the same four principles: Perceivable, Operable, Understandable, and Robust (POUR). WCAG 2.1 does not modify the existing WCAG 2.0 success criteria; it adds additional success criteria to support modern web technologies and accommodate a broader range of disabilities. The practical result is that content that conforms to WCAG 2.0 will continue to conform to all of the same success criteria in WCAG 2.1. Therefore, content that meets WCAG 2.0 needs only to be checked against the 17 new success criteria to determine if it conforms to WCAG 2.1 as well.

To ensure backward compatibility with WCAG 2.0 and help prevent confusion, WCAG 2.1 appends all-new success criteria to each guideline. The benefit of this is that no success criteria from WCAG 2.0 is rearranged, and no new success criteria from WCAG 2.1 has been placed between them – ensuring that the numbering for WCAG 2.0 success criteria remains the same in WCAG 2.1. For example, a new success criterion for guideline 1.3, “Adaptable” was introduced in WCAG 2.1. This new criterion, 1.3.4 “Orientation” was added after the existing guideline 1.3 criteria, meaning WCAG 2.0 criteria such as 1.3.1 “Info and Relationships” or 1.3.2 “Meaningful Sequence” remain unaffected.

One side effect of appending the new WCAG 2.1 success criteria after the existing WCAG 2.0 criteria is that the success criteria are no longer in order based on their WCAG conformance level. For example, in WCAG 2.0 guideline 1.4 success criteria 1.4.1-1.4.2 were level A, 1.4.3-1.4.5 were level AA, and 1.4.6-1.4.9 were level AAA. While these existing criteria remain the same in WCAG 2.1, the new guideline 1.4 success criteria, 1.4.10-1.4.13 are level AA. Therefore, it is essential to verify the level specified in the success criteria as there is no longer a correlation between the numbering of the success criteria and its WCAG conformance level.

The New WCAG 2.1 Criteria

The following list contains the 17 new success criteria introduced in WCAG 2.1, including the new success criteria number, the title of the success criteria, and the WCAG 2.1 conformance level for the new criteria.

• 1.3.4” Orientation” (AA)
• 1.3.5 “Identify Input Purpose” (AA)
• 1.3.6 “Identify Purpose” (AAA)
• 1.4.10 “Reflow” (AA)
• 1.4.11 “Non-Text Contrast” (AA)
• 1.4.12 “Text Spacing” (AA)
• 1.4.13 “Content on Hover or Focus” (AA)
• 2.1.4 “Character Key Shortcuts” (A)
• 2.2.6 “Timeouts” (AAA)
• 2.3.3 “Animation from Interactions” (AAA)
• 2.5.1 “Pointer Gestures” (A)
• 2.5.2 “Pointer Cancellation” (A)
• 2.5.3 “Label in Name” (A)
• 2.5.4 “Motion Actuation” (A)
• 2.5.5 “Target Size” (AAA)
• 2.5.6 “Concurrent Input Mechanisms” (AAA)
• 4.1.3 “Status Messages” (AA)

We’ll go into each of these new success criteria in greater detail in subsequent posts on this blog, so stay tuned!

When to start using WCAG 2.1

Here at Accessible360, we believe the time to start using WCAG 2.1 is now. By incorporating WCAG 2.1 into your development process, you’ll help ensure your web content is accessible to a broader array of users than would be achieved using WCAG 2.0. Using WCAG 2.1 now also helps future-proof your content when agencies and the courts begin to refer to these updated guidelines. In addition, if you are already under a mandate to comply with WCAG 2.0, you can fulfill this mandate by conforming to WCAG 2.1 as it is fully backward-compatible.

The post What’s In WCAG 2.1? first appeared on Allyant.