Web app accessibility - How are you handling this in your web apps?

I have a couple web apps hosted on Xojo Cloud. My apps are study guide apps, and some of my customers are colleges. One of the school’s accessibility analyst reached out to me asking about my app’s accessibility for people with disabilities and also stating:

The ADA title II update requires any product used as part of a state and local government entity’s services (including online classes for any public educational institution) must meet WCAG 2.1 level AA by April 24, 2026

My web apps are fairly new. I haven’t gotten very far with making them accessible. I also am not too sure where to start this process, so I thought to reach out to the community to see if anyone has already implemented any accessibility and may be inclined to give me some advice

There is a lot of criteria in the Website Accessibility Guidelines (WAG). I do want to start working on this to be in compliance with the ADA and was thinking of starting with the screen reader and/or keyboard navigation

For the screen reader:

  • Is there a specific tool you use to test for this? I don’t think visually impaired people simply rely on the System.Speak. I have heard of JAWS but not sure if there are others people use. I figure I will need to get myself a license of a screen reader to test everything out

For keyboard navigation:

  • Are there any “best practices” for which visually impaired people normally use? Like always use the left arrow to go back to the previous screen? Spacebar to read the text?

I’m sure I will have many more questions on this matter. Just looking to get a starting point here. I will also be asking the analyst to have a meeting with me to see if he can shed any light on what blind people expect in an app, but I’m not sure how forthcoming he will be

1 Like

Bootstrap 5.x (the basis for Xojo Web) has baked in support for WAI-ARIA, but I don’t believe it’s implemented thoroughly throughout the framework. Additionally, things like “title” attributes aren’t supported in places where they’d be beneficial for accessibility. About the only things I believe the framework handles out of the box in terms of accessibility is support for prefers-reduced-motion media feature because it’s included with Bootstrap and the fact that the HTML <button> and other basic types are screen-reader compatible on a basic level in most/all modern browsers.

The key issue you’re going to run in to with the lack of support in the framework itself for some necessary accessibility functions is that you can’t really implement them yourself without writing a bunch of JavaScript.

All of this, of course, is contingent on my memory of the last time I looked at the framework source to see how ARIA was implemented and remember noting many places that these things were missing. @Ricardo_Cruz or @Greg_O can correct me if I’m wrong.

1 Like

Thanks for the info Anthony.

I wonder if there should start to be more support on this and implementation by Xojo web app developers. I did some brief research over the weekend, and companies can be sued if they are not in compliance with the Americans with Disabilities Act. Small businesses with fewer than 15 employees are exempt from certain aspects of ADA, but it looks like all websites (and also grouped into this are web apps) must comply with accessibility requirements, regardless of the size of the company

I emailed the analyst this morning to see if he would be willing to chat about this further, so we’ll see how that goes

1 Like

I can’t speak to any legal ramifications as I’m not a lawyer, but it would be good to have extended support in all of Xojo’s frameworks for accessibility. If you haven’t opened a feedback case for Xojo to at least review accessibility support, and one doesn’t already exist, it’d be worthwhile to do so.

1 Like

Same!

I created a FR Issue. Long shot but worth putting it in the system
https://tracker.xojo.com/xojoinc/xojo/-/issues/78371

2 Likes

Thanks for opening this thread, I wasn’t aware of the requirement. The good news is we have time for fixing anything that needs to be fixed, creating that Feature Request is a leap forward. I wonder if the EU will adopt a similar requirement.

As I understand, there are things that the framework will need to do automatically, and other things that developers will have to take care of, with the tools provided by the IDE, like filling an alternative text in a WebImageViewer (which isn’t possible at the moment)

If anybody finds anything with the Web Framework that prevents complying with these requirements, please file a bug report or leave a comment in #78371.

4 Likes

They already have, but from what I can tell, the deadline for implementation has been pushed back one or more times to 2025.

2 Likes

@Ricardo_Cruz superb! Thank you for your attention to this request!

It does look like this is also a requirement in the EU, though, I am not sure about timing/deadlines

3 Likes

So I heard back from the analyst. I was expecting a “figure it out on your own”, but I got a surprisingly helpful response. Hopefully this will help others. We should all be doing our part to make our apps inclusive for all users. I added the following to the FR Issue as well

  1. Three things I use to test:
  • I recommend using NVDA for testing screen reader experience. NVDA is a free screen reader, and there are some good resources for accessibility testing with it, such as WebAIM: Using NVDA to Evaluate Web Accessibility
  • Other software I use in reviewing accessibility include WAVE. There are some other similar tools including ANDI which may be more meaningful if you aren’t an expert in accessibility, because it allows you to look at a thing at a time.
  • The other effective technique I use is tab navigation – this checks Focus order, focus visible, and other related accessibility barriers. It can be assumed that AT will emulate the keypresses tab, shift-tab, enter and space. If I cannot actuate every tool using these four buttons (aside from entering content which would be handled by the Assistive Technology emulating a keyboard), then a mobility impaired person would also not necessarily be able to actuate that tool.
  1. VI individuals fall into 2 camps: blind and low vision
  • Blind folks use screen readers which use the Accessibility Tree to navigate the website. Screen readers use a plethora of hotkeys to emulate how sighted people use websites, using headings or regions to navigate from area to area, using appropriate semantic HTML tags to understand how a page is organized.
  • Low vision folks often use lower screen resolution with magnification, so some things that they really care about are:
    • Color contrast (low contrast is more difficult to see)
    • Reflow (proper reflow on lower resolution pages means less panning and more effective use of information
    • Keyboard focus (to ensure they know what they are clicking on)
    • Keyboard (Tab) navigation (similar to physically disabled folk, the ability to navigate in a meaningful way will unnecessarily make your content harder to navigate.
  1. My priority would be the low hanging fruit.
  • Keyboard focus has to be specifically removed in CSS, it is available by default in the browser, so it’s easy to make that appear again, and it can be designed with a white square around a black square (or black around white) ensuring sufficient color contrast in all situations), if you want to make it look “better”, go for it, just make sure it is noticeable – and remember it is only used by keyboard navigation, so it should not be a “design decision”
  • Any videos should be captioned, and can be done easily using Youtube autocaptioning, then editing (and you can then download the caption file and delete the youtube video if you do not intend to host them on youtube). You can also outsource captioning for less than a dollar a minutes (we’re getting ~ $.25/min bulk pricing these days). It is critical that the captions are reviewed to determine accuracy and include punctuation to facilitate understanding
  • Update your HTML where possible with regions and specifically replace any content that should be a heading, with a heading.
  • Alt tag any images and ensure tables are properly marked up Tables Tutorial | Web Accessibility Initiative (WAI) | W3C
  • From there, you will likely need some expert support, or internal training. There are lots of companies working in this field anymore. If you want to learn it for yourself, the Deque University offerings are adequate for most simple systems.

Here is my standard spiel:

Education and all governmental entities are required to follow WCAG 2.1 level AA by April 24, 2026. WCAG primarily focuses around individuals with visual impairment, Deaf or hard of hearing, and physical disabilities.

I’m somewhat ignoring cognitive disabilities and seizure disorders because they have more to do with content, and are more “be aware of what you are posting” than things to test.

DHH

Deaf or hard of hearing support is very simple: If you add a video, make sure they are accurately captioned.

Physical disabilities

Physical disabilities includes anyone that may use assistive technology to simplify interacting with the computer. This is largely dealt with by keyboard emulation – so keyboard focus and ensuring all functionality is accessible by keyboard is the key thing here. This involves navigating your tools with the tab key, ensuring everything can be reached and that it is easy to tell where the keyboard is focused. Specific areas of concern are:

  • Forms – make sure any functional widgets like calendars and times are navigable with keyboard.
  • Modals – Modals should control focus and be escapable (meaning, pressing escape should close the modal without changing the state.
  • Generally if it is clickable it needs to have keyboard functionality. HTML by default have keyboard handlers built into tags that need keyboard handlers, but more complex apps that do not use conforming semantic HTML need to have keyboard handlers coded.

I have been told that these are good references: Patterns | APG | WAI | W3C and Inclusive Components (inclusive-components.design)

Visual disabilities

Visual disabilities are a little more complex because you have people who are low vision and people who are blind, who need different things.

People who have low vision require some of the same things as mobility impaired because they tend to get lost using a mouse. Color contrast is important to these users, especially visual keyboard focus. Reflow is critical especially enlarged on a larger screen (so don’t limit your reflow to just ios/android browser headings, a user with visual impairments may be using a 1080p monitor at 400% enlargement.) You can test this using the built in enlargement in the browser.

For blind users, screen readers and other assistive technology are how they will access content. Screen reader access benefits from someone who understands how to use a screen reader. There is a free one, NVDA which is a good one to test with. Screen reader users do not generally read “down” a page, they tend to search it, maybe looking at headings, forms and links to see if they can find a page or section of the page more directly answering their interest. Understanding shortcut keys associated with NVDA is key to navigation. This is something that is often worth outsourcing, a couple hours of time from a native keyboard user will give you fairly good feedback on where issues lie.

Screen readers particularly rely on accurate and accessible coding. WebAIM has a tool called WAVE and Deque has a tool called AXE Toolseither of which will give you feedback on accessibility issues that are automatically detectable. AXE has an IDE option for a monthly fee which may be beneficial for your developers.

Overlays, education & Outsourcing

Generally avoid panacea tools like overlays, as they only really resolve the automatically detectable issues, and do not provide “equally effective access”. The overlay isn’t the issue, but it doesn’t resolve the underlying problems. You can learn about it from the Overlay Fact Sheet. Your product is simple enough that a couple days of training of a developer will likely suffice to make your product accessible, then you do not have an ongoing cost associated with a dubiously effective overlay.

It may be beneficial to use a 3rd party to create an accessibility conformance report. It may cost a little bit, but it means that other schools will likely trust your product more, meaning it will go through procurement faster and word of mouth will benefit you over similar products. Many accessibility companies like Deque, Level Access, Allyant, AFixt, Knowbility, and many smaller companies doing the same work can package accessibility feedback, training, and documentation for a reasonable price. I cannot recommend one over the other, and there are many others in the space.

The Accessibility Association is a certifying authority for accessibility, and they have lists of free and paid conferences, including Wordpress Accessibility day (which is not WordPress Centric, primarily about web accessibility). Deque also offers AXECon for free, and signing up for the next one gives you access to the recording of the previous one (also available on Youtube). I also generally recommend Deque University’s self-paced courses. They have reasonably priced training material and it is well designed and organized for specific roles.

3 Likes

Thank you @Ryan_Hartz. That’s a lot to digest, I’ll be creating bug reports attempting to cover as much as possible.

I’ll be creating specific bug reports linked to your original Feature Request, so everyone will be aware of what is being done and when.

3 Likes

Wonderful @Ricardo_Cruz ! Again, thanks for your prompt attention. Yes, this is a ton to digest. I think baby steps is the way to go. If we can gain some support a little at a time, that will go a long way

2 Likes