13 ms·

The "Create New Project" dialog has serious accessibility problems when used with a screen reader. The buttons are clickable divs, not actual HTML buttons or ev

The "Create New Project" dialog has serious accessibility problems when used with a screen reader. The buttons are clickable divs, not actual HTML buttons or even marked up with proper ARIA. I haven't yet ventured any further into the app. Given that the app is a WebAssembly development environment, my first guess was that it was built in WebAssembly itself, with a custom UI framework. But in fact, it's plain React, using its own home-grown components for basic things like buttons. It breaks my heart that when this project was started in 2017, some 20 years after web accessibility advocacy had started in earnest, the developer was still uninformed enough about accessibility that they would create a custom button component with no ARIA support. I suppose we could also blame the web platform for making it hard enough to customize the look of a standard button that the developer would reach for the div tag. What do we do about this?

CyberDildonics 6y ago
There is a github link at he top right, you could start there.
- mwcampbell 6y ago
  I was talking about the general problem of new inaccessible apps being developed, not this specific project.
  - skrebbel 6y ago
    What do you think is a good starting point for developers who want to get better at this? For example, do you know of a good way for developers with no disabilities to get an impression of how a site works in various screen readers?
    - spicybright 6y ago
      The accessibility mode in the firefox debugger is a good start.
      - skrebbel 6y ago
        Wow nice! I feel pretty stupid for just having looked over that all the time. It comes pretty close to what I hoped to get. I do see some surprising behavior though, eg I ran it on WhatsApp Web, where it complains about image links that have no `alt`. But these links do have a `title`. Wouldn't every screen reader fall back to the `title` when there's no `alt`? What I mean is, is that an actual issue or just a "satisfy the tool" level thing to fix? I'm not sure how people build up an intuition for stuff like this, any suggestions?
        crisnoble 6y ago
        If you are using a mac, try using the web for a few minutes with the built in screen reader turned on. It is actually pretty fun, and definitely helps get a feel for what a non sighted user would be dealing with. Your example with alt is a good one, but they should still have an empty alt if it is not needed/applicable. Here is an intro to voiceover https://webaim.org/articles/voiceover/ https://webaim.org/articles/voiceover/
abellerose 6y ago
..
- scotth 6y ago
  I mean, this is exactly what aria attributes are for, right?
  - deleted 6y ago
    [deleted]
- detaro 6y ago
  This already exists, and many developers don't use it.
- Nicksil 6y ago
  > There should be a way to signal to browser a div will be used for a button or whatever and I believe people would be happy to use such a solution. That solution already exists: replace "div" with "button"
  - deleted 6y ago
    [deleted]
- ratww 6y ago
  You can use the ARIA role="button" attribute [1]. You also should make it focusable using tabindex="0" and allow keyboard input, although some screen readers might be able to get around those limitations... But like another reply mentioned, you can get it all from free using a normal <button>, which isn't really hard to style even compared to a <div>, and provides it all for free... [1] https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/button_role https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
- mwcampbell 6y ago
  I'm sorry if I made you feel that you should be ashamed of your lack of knowledge in this particular area. That wasn't my point at all. I'm just sad that we accessibility advocates have somehow not yet been able to reach you and other developers. I'm sorry you felt the need to retract your comment.
bavell 6y ago
I'm guilty of this more often than I should be. I think the reason I sometimes reach for divs over buttons or other semantic elements is because I've been burned by default browser behavior treating them special when I just want a dumb box with a dumb click handler - no default styling that I need to override, no need to call .preventDefault(), no need to worry about the matrix of OS+browser+device that each treats a button slightly differently, etc etc... Some of this fear may be unfounded or now obsolete but years ago it wasn't fun fixing bugs clients ran into due to silly issues caused by these kinds of things.
- mwcampbell 6y ago
  Thanks for sharing your perspective on this. Does anyone know if the web platform now provides a foolproof way to clear all default styling on a button or other standard control?
  - crisnoble 6y ago
    `appearance: none;` gets you a long way
    - plussed_reader 6y ago
      But muh ableist design preferences....
      - mwcampbell 6y ago
        Please avoid this kind of unconstructive snark. I'm prone to it myself when discussing this subject, but I try to avoid it when discussing accessibility with a broad audience like HN. I want to meet mainstream developers where they are, figure out what prevents them from making their applications accessible, and do something about it, not just guilt-trip them.
        crisnoble 6y ago
        I actually use <button> with appearance:none specifically for accessibility. You get all of the benefits of a button's accessibility, focus, click events, normal tabbing, etc, and can use them for things like toggling an accordion of content or showing/hiding a mobile menu. Better than a div because you don't need aria-role, and better than a link because it is not taking you anywhere. As pointed out up thread, developers and designers often skip using <button> because it is hard to style just right. Using appearance:none resets the style but not the accessibility behavior.
david_dan 6y ago
All the greatest products/services in the world started targeting the healthy, the rich, or the white. May be a11y, l10n are the premature optimization equivalent of product design?
zamadatix 6y ago
Why assume ignorance/difficulty when the reality is not everyone is going to focus on adding/maintaining accessibility when they haven't even built out their beta MIT licensed side project? It'd certainly be nice if everything just automagically worked about accessible UI but we're not there yet (getting anything to automagically work in UI is a pain still). As far as what we can do about it I suppose outside of somehow translating thoughts into perfect UI automatically we can try to add coverage to these projects as we can prioritize it. After all that's why they are being built in the open with an open license, so others can help add functionality.
- spicybright 6y ago
  Exactly this. Yes, accessibility is very important, but as of right now, it takes non-zero effort to implement correctly. So you must balance that with other priorities depending on the goals of the project.
  - thwarted 6y ago
    The goals of the project includes "custom buttons"? There's so much functionality that you get for free/low effort if you don't feel the need to customize everything to the nines.
    - Wowfunhappy 6y ago
      When I decided to make myself a personal website this summer, my goals were: • It has to have lots of custom animations, because animations are fun. • It has to work well in weird text-based browsers like Links, because being able to load my site up in those feels cool. • It has to support Safari 6, because that's the last version of Safari that works in Snow Leopard. If it's a non-commercial project, the goals can be whatever the fuck the author wants them to be.
      - spicybright 6y ago
        Right? One of my peeves with a lot of developers is when they treat every programming project like it's a commercial start up. There's no reason "learning to implement custom buttons" can't be on your list of goals.
alpaca128 6y ago
Other tools like Vim browser plugins suffer from this issue as well, making those UI components impossible to interact with. Meanwhile other sites often have 5 clickable buttons bunched up within each other or very close together for no reason. The way many modern sites are frequently built is broken once the user takes a closer look.
clickness 6y ago
I read your comment as unnecessarily abrasive, self-entitled almost. > "It breaks my heart that when this project was started in 2017, some 20 years after web accessibility advocacy had started in earnest, the developer was still uninformed enough about accessibility that they would create a custom button component with no ARIA support." You're assuming ignorance and malice, when in all actuality this most likely comes down to priorities, and a painful lack of clear standards and tooling. By all means - please submit a patch with what you deem is the right solution here, instead of just expecting things get done your way on day one. > "The buttons are clickable divs, not actual HTML buttons" What's an "actual" HTML button we can all safely use to replace simple divs (which are just about the only way to get content to show up and behave uniformely across browsers and platforms, using as little js/css hacks as possible)?
- joshjhargreaves 6y ago
  It's almost as if some people get off on the feeling of self-importance they get for 'calling people out' in this manner- the neckbeards of accessibility. In an ideal world, accessibility would come for free - but unfortunately it does not. Yes I would argue that morally projects should do their best to support it - but even at well established companies it takes significant resources to maintain accessibility. Yes in this case it may be as simple as using native Buttons, as the above comment said, 'that's as far as I got'. Just pretending that accessibility isn't a significant time an resources doesn't make it any less so. If this wasn't true then there wouldn't be legislation to essentially address this market-failure.
  - curryst 6y ago
    It's an intractable problem; most people believe software should be accessible to people with different needs, and most people also believe that other people shouldn't be able to force you to do work for free. Which one you decide on seems like a value judgement to me. Is it fair that instead of shipping that feature you really want this month, you have to do accessibility features? I don't think the answer is black and white. FWIW, accessibility seems hard. I am not a good web dev, and the conversations that spin out from these accessibility conversations frequently go right over my head. I can build a pretty basic React site, but I have no idea how to add accessibility components to that, or how I would test whether my site is accessible or not. Part of this problem is probably lack of exposure. I know what a screenreader is, but I don't know how they work. I don't know what makes it easy to traverse a page with a screenreader and what makes it hard. It would probably help a lot if we forced devs to have experience with accessibility tools so they know they work.
deleted 6y ago
[deleted]
pickpuck 6y ago
> What do we do about this? https://www.youtube.com/watch?v=DBcz_bGcHgk https://www.youtube.com/watch?v=DBcz_bGcHgk After watching this video from Google, I think the future is web components + AOM[1]. This makes sense to me because: 1) Most web developers are already using frameworks (such as React) which can render web components. 2) We can't expect all web developers to be ARIA/WCAG/ADA experts — they're always going to be trying to write code that quickly/efficiently expresses their intent. Once we get full buy-in and implementation in all browsers and screen readers, most web developers probably won't be using <button> much anymore. Instead, they'll be using <framework-button>. The <framework-button> sets up all the appropriate ARIA properties/attributes, can restrict what slot content it accepts, and can present remaining issues as errors in the console. Perhaps under the hood <framework-button> does indeed include a <button> in its Shadow DOM, or maybe it's a <span>. Coupled with Houdini and some other emerging standards, I think AOM will finally make web components a viable option for most developers, and can solve the vast majority of accessibility issues we see today. [1]: https://wicg.github.io/aom/explainer.html#motivating-use-cases https://wicg.github.io/aom/explainer.html#motivating-use-cas...
corytheboyd 6y ago
I agree that building an accessible internet should be everyone’s goal, but let’s be real here and assign blame correctly. The openness of the technology and the internet itself is what killed accessibility for the masses. Point 1: HTML, assuming an at-least-okay following of semantics, should be accessible by default. Add the planes of JS and CSS though and it’s insanely easy to create non-accessible content. Point 2: There is no education about accessibility tech. I don’t just mean about how to create accessible content, I mean about the devices themselves. I’m speaking for myself, I hardly know anything about these devices to be honest. Without an idea of how they work, it’s that much harder to keep them in mind when making design considerations. Point 3: It’s insanely easy to create and host content. With such a low barrier of entry you’re going to get more low quality content. In the real world, there are strict requirements for businesses to make themselves accessible. There is no version of that for web content. Well, for the most part, until you “make it” at which point I believe you CAN actually be fined for having inaccessible web content. Take that with a grain of salt I’m recalling from shaky memory of reading HN comments. So, what do we do about this? Honestly I think the only thing we CAN do is solve the education part. As children we should be required to be exposed to and educated about these amazing technologies that assist people with disabilities. Because all of us should know, not just us people in the software business (though in this case of course, ESPECIALLY people in the software business) There is no way to fix the technology stack itself. It’s just been dug into such a deep hole. We can try to add things to it to make building accessible content easier... but that will add to the problem of there already being a million and one different ways of doing the same thing (where a couple of them are accessible)
hobby-coder-guy 6y ago
“Hey, here are some tips on making your site more accessible”
cassetti 6y ago
> It breaks my heart This is all a little dramatic, no? It's a cool app that can be easily updated to fix button accessibility.
- mwcampbell 6y ago
  Yes, on second thought, that one sentence was probably melodramatic.
- chrismorgan 6y ago
  > It's a cool app that can be easily updated to fix button accessibility. Well… no, not really, because it’s not just about the buttons. I invariably find that things like this are systemic, so that individual symptoms may be fixed fairly easily, but that there are just lots of basic problems with the markup employed, all of which need to be fixed, and some of which are actually hard to fix because of bad assumptions.
k4rli 6y ago
Do development tools really need a11y? I haven't come across anyone with this need before.
- mwcampbell 6y ago
  There are, in fact, blind programmers, and programmers with other disabilities.
drevil-v2 6y ago
Jesus F Christ mate... take it easy. You sound like you have been personally attacked. Gathering up the mob and sharpening your pitchfork to tear down someone else's work is easy. Why don't you start with opening an issue on their Github first? And maybe contribute the code yourself since you feel so strongly about it.
john_moscow 6y ago
It's about priorities. Adding accessibility is a feature, just like syntax coloring or debugging. And the reasonable way to prioritize the features is to look at how much effort would it take to implement a feature (and maintain/support it in the long term!) vs. how many new users will it bring. If you are designing a custom control framework from scratch, supporting accessibility properly is not trivial, and the amount of new users it would bring you pales in comparison with almost any use case-focused feature. So it makes sense that the author would not be willing to implement it. I also don't like the current approach of arbitrarily targeting small vendors and shaming them into putting unpaid time into a feature that will not pay off for them. It surely gives you the sense of power and moral superiority, but it is extremely toxic and demotivating to small vendors. I think, a better alternative for people concerned about accessibility would be to offer free help adding accessibility to the products they are concerned about. I am certain, had you approached the author with a ready-to-use pull request instead of calling them ignorant, they would have thanked you and merged your changes into the code base ASAP.

CyberDildonics 6y ago

There is a github link at he top right, you could start there.

mwcampbell 6y ago
I was talking about the general problem of new inaccessible apps being developed, not this specific project.
- skrebbel 6y ago
  What do you think is a good starting point for developers who want to get better at this? For example, do you know of a good way for developers with no disabilities to get an impression of how a site works in various screen readers?
  - spicybright 6y ago
    The accessibility mode in the firefox debugger is a good start.
    - skrebbel 6y ago
      Wow nice! I feel pretty stupid for just having looked over that all the time. It comes pretty close to what I hoped to get. I do see some surprising behavior though, eg I ran it on WhatsApp Web, where it complains about image links that have no `alt`. But these links do have a `title`. Wouldn't every screen reader fall back to the `title` when there's no `alt`? What I mean is, is that an actual issue or just a "satisfy the tool" level thing to fix? I'm not sure how people build up an intuition for stuff like this, any suggestions?
      - crisnoble 6y ago
        If you are using a mac, try using the web for a few minutes with the built in screen reader turned on. It is actually pretty fun, and definitely helps get a feel for what a non sighted user would be dealing with. Your example with alt is a good one, but they should still have an empty alt if it is not needed/applicable. Here is an intro to voiceover https://webaim.org/articles/voiceover/ https://webaim.org/articles/voiceover/

abellerose 6y ago

scotth 6y ago
I mean, this is exactly what aria attributes are for, right?
- deleted 6y ago
  [deleted]
detaro 6y ago
This already exists, and many developers don't use it.
Nicksil 6y ago
> There should be a way to signal to browser a div will be used for a button or whatever and I believe people would be happy to use such a solution. That solution already exists: replace "div" with "button"
- deleted 6y ago
  [deleted]
ratww 6y ago
You can use the ARIA role="button" attribute [1]. You also should make it focusable using tabindex="0" and allow keyboard input, although some screen readers might be able to get around those limitations... But like another reply mentioned, you can get it all from free using a normal <button>, which isn't really hard to style even compared to a <div>, and provides it all for free... [1] https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/button_role https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
mwcampbell 6y ago
I'm sorry if I made you feel that you should be ashamed of your lack of knowledge in this particular area. That wasn't my point at all. I'm just sad that we accessibility advocates have somehow not yet been able to reach you and other developers. I'm sorry you felt the need to retract your comment.

bavell 6y ago

I'm guilty of this more often than I should be. I think the reason I sometimes reach for divs over buttons or other semantic elements is because I've been burned by default browser behavior treating them special when I just want a dumb box with a dumb click handler - no default styling that I need to override, no need to call .preventDefault(), no need to worry about the matrix of OS+browser+device that each treats a button slightly differently, etc etc... Some of this fear may be unfounded or now obsolete but years ago it wasn't fun fixing bugs clients ran into due to silly issues caused by these kinds of things.

mwcampbell 6y ago
Thanks for sharing your perspective on this. Does anyone know if the web platform now provides a foolproof way to clear all default styling on a button or other standard control?
- crisnoble 6y ago
  `appearance: none;` gets you a long way
  - plussed_reader 6y ago
    But muh ableist design preferences....
    - mwcampbell 6y ago
      Please avoid this kind of unconstructive snark. I'm prone to it myself when discussing this subject, but I try to avoid it when discussing accessibility with a broad audience like HN. I want to meet mainstream developers where they are, figure out what prevents them from making their applications accessible, and do something about it, not just guilt-trip them.
      - crisnoble 6y ago
        I actually use <button> with appearance:none specifically for accessibility. You get all of the benefits of a button's accessibility, focus, click events, normal tabbing, etc, and can use them for things like toggling an accordion of content or showing/hiding a mobile menu. Better than a div because you don't need aria-role, and better than a link because it is not taking you anywhere. As pointed out up thread, developers and designers often skip using <button> because it is hard to style just right. Using appearance:none resets the style but not the accessibility behavior.

david_dan 6y ago

All the greatest products/services in the world started targeting the healthy, the rich, or the white. May be a11y, l10n are the premature optimization equivalent of product design?

zamadatix 6y ago

Why assume ignorance/difficulty when the reality is not everyone is going to focus on adding/maintaining accessibility when they haven't even built out their beta MIT licensed side project? It'd certainly be nice if everything just automagically worked about accessible UI but we're not there yet (getting anything to automagically work in UI is a pain still). As far as what we can do about it I suppose outside of somehow translating thoughts into perfect UI automatically we can try to add coverage to these projects as we can prioritize it. After all that's why they are being built in the open with an open license, so others can help add functionality.

spicybright 6y ago
Exactly this. Yes, accessibility is very important, but as of right now, it takes non-zero effort to implement correctly. So you must balance that with other priorities depending on the goals of the project.
- thwarted 6y ago
  The goals of the project includes "custom buttons"? There's so much functionality that you get for free/low effort if you don't feel the need to customize everything to the nines.
  - Wowfunhappy 6y ago
    When I decided to make myself a personal website this summer, my goals were: • It has to have lots of custom animations, because animations are fun. • It has to work well in weird text-based browsers like Links, because being able to load my site up in those feels cool. • It has to support Safari 6, because that's the last version of Safari that works in Snow Leopard. If it's a non-commercial project, the goals can be whatever the fuck the author wants them to be.
    - spicybright 6y ago
      Right? One of my peeves with a lot of developers is when they treat every programming project like it's a commercial start up. There's no reason "learning to implement custom buttons" can't be on your list of goals.

alpaca128 6y ago

Other tools like Vim browser plugins suffer from this issue as well, making those UI components impossible to interact with. Meanwhile other sites often have 5 clickable buttons bunched up within each other or very close together for no reason. The way many modern sites are frequently built is broken once the user takes a closer look.

clickness 6y ago

I read your comment as unnecessarily abrasive, self-entitled almost. > "It breaks my heart that when this project was started in 2017, some 20 years after web accessibility advocacy had started in earnest, the developer was still uninformed enough about accessibility that they would create a custom button component with no ARIA support." You're assuming ignorance and malice, when in all actuality this most likely comes down to priorities, and a painful lack of clear standards and tooling. By all means - please submit a patch with what you deem is the right solution here, instead of just expecting things get done your way on day one. > "The buttons are clickable divs, not actual HTML buttons" What's an "actual" HTML button we can all safely use to replace simple divs (which are just about the only way to get content to show up and behave uniformely across browsers and platforms, using as little js/css hacks as possible)?

joshjhargreaves 6y ago
It's almost as if some people get off on the feeling of self-importance they get for 'calling people out' in this manner- the neckbeards of accessibility. In an ideal world, accessibility would come for free - but unfortunately it does not. Yes I would argue that morally projects should do their best to support it - but even at well established companies it takes significant resources to maintain accessibility. Yes in this case it may be as simple as using native Buttons, as the above comment said, 'that's as far as I got'. Just pretending that accessibility isn't a significant time an resources doesn't make it any less so. If this wasn't true then there wouldn't be legislation to essentially address this market-failure.
- curryst 6y ago
  It's an intractable problem; most people believe software should be accessible to people with different needs, and most people also believe that other people shouldn't be able to force you to do work for free. Which one you decide on seems like a value judgement to me. Is it fair that instead of shipping that feature you really want this month, you have to do accessibility features? I don't think the answer is black and white. FWIW, accessibility seems hard. I am not a good web dev, and the conversations that spin out from these accessibility conversations frequently go right over my head. I can build a pretty basic React site, but I have no idea how to add accessibility components to that, or how I would test whether my site is accessible or not. Part of this problem is probably lack of exposure. I know what a screenreader is, but I don't know how they work. I don't know what makes it easy to traverse a page with a screenreader and what makes it hard. It would probably help a lot if we forced devs to have experience with accessibility tools so they know they work.

deleted 6y ago

[deleted]

pickpuck 6y ago

> What do we do about this? https://www.youtube.com/watch?v=DBcz_bGcHgk https://www.youtube.com/watch?v=DBcz_bGcHgk After watching this video from Google, I think the future is web components + AOM[1]. This makes sense to me because: 1) Most web developers are already using frameworks (such as React) which can render web components. 2) We can't expect all web developers to be ARIA/WCAG/ADA experts — they're always going to be trying to write code that quickly/efficiently expresses their intent. Once we get full buy-in and implementation in all browsers and screen readers, most web developers probably won't be using <button> much anymore. Instead, they'll be using <framework-button>. The <framework-button> sets up all the appropriate ARIA properties/attributes, can restrict what slot content it accepts, and can present remaining issues as errors in the console. Perhaps under the hood <framework-button> does indeed include a <button> in its Shadow DOM, or maybe it's a <span>. Coupled with Houdini and some other emerging standards, I think AOM will finally make web components a viable option for most developers, and can solve the vast majority of accessibility issues we see today. [1]: https://wicg.github.io/aom/explainer.html#motivating-use-cases https://wicg.github.io/aom/explainer.html#motivating-use-cas...

corytheboyd 6y ago

I agree that building an accessible internet should be everyone’s goal, but let’s be real here and assign blame correctly. The openness of the technology and the internet itself is what killed accessibility for the masses. Point 1: HTML, assuming an at-least-okay following of semantics, should be accessible by default. Add the planes of JS and CSS though and it’s insanely easy to create non-accessible content. Point 2: There is no education about accessibility tech. I don’t just mean about how to create accessible content, I mean about the devices themselves. I’m speaking for myself, I hardly know anything about these devices to be honest. Without an idea of how they work, it’s that much harder to keep them in mind when making design considerations. Point 3: It’s insanely easy to create and host content. With such a low barrier of entry you’re going to get more low quality content. In the real world, there are strict requirements for businesses to make themselves accessible. There is no version of that for web content. Well, for the most part, until you “make it” at which point I believe you CAN actually be fined for having inaccessible web content. Take that with a grain of salt I’m recalling from shaky memory of reading HN comments. So, what do we do about this? Honestly I think the only thing we CAN do is solve the education part. As children we should be required to be exposed to and educated about these amazing technologies that assist people with disabilities. Because all of us should know, not just us people in the software business (though in this case of course, ESPECIALLY people in the software business) There is no way to fix the technology stack itself. It’s just been dug into such a deep hole. We can try to add things to it to make building accessible content easier... but that will add to the problem of there already being a million and one different ways of doing the same thing (where a couple of them are accessible)

hobby-coder-guy 6y ago

“Hey, here are some tips on making your site more accessible”

cassetti 6y ago

> It breaks my heart This is all a little dramatic, no? It's a cool app that can be easily updated to fix button accessibility.

mwcampbell 6y ago
Yes, on second thought, that one sentence was probably melodramatic.
chrismorgan 6y ago
> It's a cool app that can be easily updated to fix button accessibility. Well… no, not really, because it’s not just about the buttons. I invariably find that things like this are systemic, so that individual symptoms may be fixed fairly easily, but that there are just lots of basic problems with the markup employed, all of which need to be fixed, and some of which are actually hard to fix because of bad assumptions.

k4rli 6y ago

Do development tools really need a11y? I haven't come across anyone with this need before.

mwcampbell 6y ago
There are, in fact, blind programmers, and programmers with other disabilities.

drevil-v2 6y ago

Jesus F Christ mate... take it easy. You sound like you have been personally attacked. Gathering up the mob and sharpening your pitchfork to tear down someone else's work is easy. Why don't you start with opening an issue on their Github first? And maybe contribute the code yourself since you feel so strongly about it.

john_moscow 6y ago

It's about priorities. Adding accessibility is a feature, just like syntax coloring or debugging. And the reasonable way to prioritize the features is to look at how much effort would it take to implement a feature (and maintain/support it in the long term!) vs. how many new users will it bring. If you are designing a custom control framework from scratch, supporting accessibility properly is not trivial, and the amount of new users it would bring you pales in comparison with almost any use case-focused feature. So it makes sense that the author would not be willing to implement it. I also don't like the current approach of arbitrarily targeting small vendors and shaming them into putting unpaid time into a feature that will not pay off for them. It surely gives you the sense of power and moral superiority, but it is extremely toxic and demotivating to small vendors. I think, a better alternative for people concerned about accessibility would be to offer free help adding accessibility to the products they are concerned about. I am certain, had you approached the author with a ready-to-use pull request instead of calling them ignorant, they would have thanked you and merged your changes into the code base ASAP.