Accessibility documentation

[joppehoekstra]

The current documentation is very limited regarding the accessibility of Quasar. All it says is "Accessibility features" on the Why Quasar page.

Since the rest of the Quasar documentation is very extensive, even covering topics not directly related to Quasar, I was surprised to see this important topic being skipped. Vuetify does have an entire page dedicated to this topic.

I would love to see the following:

• Documentation on how Quasar components take accessibility into account
• Documentation on how to use Quasar in the most accessible way
• External resources to cover topics related to accessibility, which are not already included in Quasar by default

[pdanpdan]

To be honest I don't know what we should write there.

We try to render all the ARIA attributes that can be inferred from the info we have (state, props, ...) from the components and if you find something missing/wrong please tell us :)

I cannot write a novel with the subject: we didn't break native TAB navigation

[joppehoekstra]

Well, there's a lot more to web accessibility than that. I don't know that much about it myself either I'm afraid, but perhaps the A11Y Project could be of help here.

As a start, I would recommend checking all components using the Lighthouse accessibility analysis tool.

I found issues #11895 and #11894 because I happened to use those components on my page and scanned it with Lighthouse. But it would be great if all Quasar components go through a test by default.

More generally speaking, I think it would be great if this topic were properly addressed in the documentation, showing this really is a matter of importance to the Quasar community. And, of course, I'll let you know whenever I find a concrete accessibility issue ❤️

[pbb72]

Accessibility is a huge subject. And just to shatter a dream; no tool can ever be 100% accessible. (It's even more unattainable than being 100% bug-free.) This also means that people depending on accessibility, already know you're not going to be fully accessible.

So a good place to start documenting, is to list which accessibility features Quasar aims to support. Some features can be expected to be build-in (such as keyboard navigation), while others will need to be implemented by developers using Quasar (such as landmarks).

Some basic accessibility features you can start the list with:

• Keyboard support (can every feature be used without ever touching the mouse?)
• Color contrast (W3C provides minimum values and a formula to calculate contrast at https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html#key-terms, under "contrast ratio".)
• Textual alternatives (any graphical content that is vital for understanding the element, needs to provide an (invisible) text alternative.)

And just as a quick note:

we didn't break native TAB navigation

Yes, there are Quasar elements that do break tab navigation.

[StefanCardnell]

@pdanpdan It's reasonable to assume that if nothing is said about accessibility then the framework doesn't make effort in supporting it (since so many frameworks don't). Hilariously to me PrimeNG states accessibility is a major concern but their dropdowns aren't read with a screen reader. Quasar seems to get it right without saying anything.

However it's quite hard to convince teams or higher ups to adopt Quasar if accessibility is a frontline concern of theirs. In some countries it's legally required to provide an accessible UI, and/or some customers will specifically require it. With nothing in the docs to back it up it can't be considered as a framework of choice. Even just a few lines say "we're really focused on making our components accessible" goes a long way. I can see by searching Github tickets there's been some work on it, but I suspect a lot of people won't go that far in their investigation.

[pdanpdan]

I hate bullshit, so I'll not make a PR about "accessibility is very important for us".

But I do agree we need:

• an assessment of the already implemented a11y in each component
• a list of what must be implemented internally in quasar (like in the case of QSelect)
• improve the documentation with what is already provided

Any help would be appreciated

[nurielmeni]

It looks like no a11y is supported in Quasar

[pdanpdan]

That comparison is done by verify and if you check they do everything and other frameworks do nothing.
Their team is very good at pr:)

[nurielmeni]

Sure, I know, but there should be some PR, or leave the PR, just some information on the a11y quasar do provide. For me as developer using Quasar, it helps by presenting the a11y support the framework deliver.

By the way, i love Quasar!!!

[yusufkandemir]

Let me share my answer to someone that asked about a11y on our Discord server last week:
https://discord.com/channels/415874313728688138/856517299816497173/1050050420451586089

Hi 👋 First of all, that entry in our roadmap is completed and released. We have some open issues left when you search "a11y":
https://github.com/quasarframework/quasar/issues?q=a11y+is:open
One in the list is unrelated to a11y (SSR-related)
One is for improving our documentation about a11y, which we should do
The other one is about keyboard navigation and QSelect, but I am not sure if it violates any a11y spec. So, I'd say there are no fully a11y related functional open issues, at the time of writing.

I wouldn't trust that chart 100% since we had to get in contact to correct some info before. In general, comparison charts tend to be biased, especially more so if the author of a product prepares it.

I am honestly not sure if it's ok to say just "508 compliance" without a certificate or proof of sorts. I've found this ancient issue which is closed because it's not a valid issue, but more of a discussion: vuetifyjs/vuetify#3780
This 2+ years old issue says at least VSelect is not fully a11y compliant:
vuetifyjs/vuetify#11613
There are other open a11y-related issues as well:
https://github.com/vuetifyjs/vuetify/issues?q=a11y+is:open

So, Quasar does a lot of stuff about a11y, tries to fix a11y related issues when they are raised, as much as possible. But, doesn't market itself as fully a11y-compliant, because there is no definite way I know to go over every little scenario to know it. Vuetify cares a lot about a11y, and it looks like doing slightly worse since there are quite old issues, at least at the time of writing, but markets itself as fully compliant. So, it seems to me that either is fine as long as the parts you'll use seem to be compliant. If not, you may try to patch it yourself via natural ways, e.g. passing attributes, overriding content via slots, adding new behavior, etc. or you can create an issue so it gets solved. This applies to pretty much any framework out there.

Also, another thing about the chart there:
https://github.com/quasarframework/quasar/blob/dev/ROADMAP.md#support-policy-and-schedule

Version	Status	Released	Active support ends	LTS support ends
2.x	Active	2021-06-21	After 2022-04-01	After 2023-04-01
1.x	Active	2019-03-07	2021-04-01	2022-12-31

They are correct that we don't provide 18 Months LTS, because we provide more than that 🙂 ~46 months for Qv1, ~21 months for Qv2. Both of them, especially Qv2 will be potentially supported for even longer than planned. This version of the chart is the "corrected" version, the old version had tree-shaking as "manual", and contained more mistakes. So, in short, I wouldn't trust that chart too much, it's biased and contains false information, and can get outdated really quickly.

So, anyways, we do care about a11y, and we've spent a good amount of effort to improve a11y support, mostly, if not entirely, thanks to @pdanpdan. We are trying to resolve a11y issues as they are reported. We can't say we are definitely 100% covered, we have no proof of that, but we are covered on a11y side as far as we and our users are aware. As @pdanpdan pointed out, we have to document which component gets which a11y treatment, whether the developers themselves should handle a specific treatment, etc. We should also have some automated tests that use a tool like axe so that we are constantly monitoring a11y. But, all these need time, effort, and knowledge, which we don't have enough of, unfortunately. So, if anyone is interested in this topic, please don't hesitate to provide more info, create a PR, etc.

[HarisSpahija]

Sorry hate to break this one open again but with upcomming 2025 EAA might be good to take a look at this again.

@yusufkandemir Would it make sense for us to tackle automated testing if we implemented Storybook? Most of storybook is very heavy on A11Y and with the upcomming 2025 EAA regulations I can only see this increase.

It also has Axe built in https://storybook.js.org/addons/@storybook/addon-a11y so it might be a perfect fit. We will be diving into implementing storybook in our quasar project the next comming weeks and see what axe reports to us already

[ENINSIIMA]

I am hitting a lot of blockers with quasar with regard to accessibility.

• Quasar's q-item doesn't provide a way to change the a tag’s role attribute through its props or slots.

-Quasar's carousel's control buttons don't have discernible text

[yusufkandemir]

@HarisSpahija do you have any updates? Did you manage to integrate Storybook and test out Axe?

[yusufkandemir]

@ENINSIIMA

Quasar's q-item doesn't provide a way to change the a tag’s role attribute through its props or slots.

You don't need a prop to do that, you can do it through attributes:
https://codepen.io/yusufkandemir/pen/zYQBNaq?editors=101
As suggested in #17162, the overall experience could be improved by automatically applying role="menuitem" while it's placed in a q-menu, for example. But, it's possible to do that manually now.

Quasar's carousel's control buttons don't have discernible text

I guess you mean the non-numbered pagination items and also the next and previous buttons, yes that's correct. Unfortunately, it's not the only component that has this problem. But, please open a separate issue for this so we can track it in an easier way. This issue is about documenting a11y stuff, not reporting/fixing the faulty aspects. Thanks.