The reason I ask is because it would be helpful to have a streamlined place to send people who have accessibility issues with Fedora, whether that’s something on this forum, making a ticket in GitLab, or something else.
I can also dump feedback I see online into that same place for folks who are having issues but may not take the time to talk about their issue outside of a social media post. I won’t always do that, but I can make an exception for accessibility because it’s an important issue and one of our objectives for Strategy 2028.
We also may need to think about how we circulate feedback to upstream projects. For example, someone in the Mastodon thread I linked shared an issue with Gnome, which isn’t really something we cover. However, we do work closely with the project and can probably communicate this with them. From that perspective we can function as hub to improve accessibility upstream for projects who may not have their own accessibility initiatives.
The A11y WG is in its initial formation stages at the moment, but we do want to provide a place for users to share / file their issues, and we would attempt to connect them with the right team / people.
The mission and vision statement for the group are still in creation, but your feedback would be appreciated! Especially from someone who deals with users on social media.
This is just an idea that I’m not sure will work, but I wonder if we could set up a separate GitLab repo that is specifically for “Fedora Accessibility Feedback” so that tickets like these don’t mix with the ones you’re using for internal team tasks. It could also be helpful for the Quality Team if it’s separate so that they know that every ticket they’re seeing is related to an accessibility issue. Would love to hear from someone on that team for what there thoughts are on a good process.
My first thought is that creating more than one GitLab repo while we are still early days in this work might be premature. I suspect we are not yet equipped to triage and respond to this kind of feedback. Keeping it in one place, for now, at least gives us one common place to start surfacing ideas, feedback, and improvements.
In general though, I am not sure we are ready to open the floodgates for feedback on accessibility. It is valuable information, but I do not want to set up an expectation that we are equipped and ready to act on every piece of feedback we get.
A separate repo might be a good idea after we prove the concept of the Working Group and have an idea of how to prioritize and respond to user feedback.
This is an area where I could learn a lot. Across my years in Fedora, I have not gone deep in the quality end of things in Fedora.
I am also not sure how accessibility-related feedback would be exposed to the Quality Team. Is it Bugzilla tickets?
I think we could also point to people to Bugzilla is that’s preferred. As long as there’s a place where we can point people to and not have it lost, I think we’re good.
The only concern I have with a Quality Team focused ticket repo is that not every point of feedback that we get about accessibility is something they can work on. We would have to take that into account so that tickets that aren’t actionable for the Quality team are still tracked for communicating with upstream projects.
@joseph ,
The link you posted to the discussion, well the discussion is pretty subjective and also I think if someone is needing a screen reader to install we should point them to the Live media installer since it boots up a working Gnome DE, which has as working screen reader.
Apparently Orca, the screen reader that is supposed to work for Gnome, doesn’t work right now when it’s open in a Wayland session. That’s a problem because Wayland is the default for Workstation and Fedora KDE. If someone needs a screen reader, they may not be able to switch to an X11 session.
This post on Mastodon came up highlighting the issue so I want to flag it again and see what we can be doing on our end. I spoke with @ngompa recently and he said that this is something that is fixed in Fedora KDE or will be fixed when Fedora KDE 40 releases. I don’t know how hard it is to enable Orca to work right now, but I think it’s important to address in Workstation.
Will drop this in the Workstation WG matrix for an update.
I was trying to follow that discussion, it seems like it involves modifier keys that are used with Orca for some purpose; so possibly the issue isn’t that it literally does not work, but that you can’t use the modifier keys to do something that’s more or less required to use it practically? I just don’t know how you actually use a screen reader in practice, so it’s hard to understand I have tested this occasionally, but all I knew to do was start Orca up and see if it said something. I had no idea how to know if it’s really “usable”.
Michael Catanzaro clarified that this was related to keybindings not working like what Adam mentioned and that they got the funding needed to get that fixed. As far as I can see it is a problem, but I am also unsure how big it is, just that it was pointed out.
This is a good point that I would like clarification on from a process standpoint. I’m just a marketing guy doing his best to parse feedback I see out in the wild. Normally I won’t bring complaints or bugs that should be bug reports to the community because it’s too much and I would run into this problem of mentioning a bug that isn’t actually a bug.
With accessibility issues I want to make the exception because these folks may not be plugged in enough to the community to make bug reports, and yet their feedback is the most relevant to us. At the same time I don’t want to waste people’s time with non-problems just because I don’t know enough to determine which is which.
I have tested this occasionally, but all I knew to do was start Orca up and see if it said something. I had no idea how to know if it’s really “usable”.