App is nearly inaccessible for blind users #7595
Comments
|
I noticed the other day that tab traversal is mostly broken in the app. It sometimes works, but only if the focus is in the right place. The settings tabs can be traversed with tab, but only after the top bar receives focus. I'm sure you know this, but I'm just putting down what I know. I've been tinkering with PS for over a year, and I would love to help out in any way I can to make PS more accessible to everyone. I already did some work for color vision deficiencies. (You'll have to take my word for that 😀 ) Since it sounds like you know programming, and probably better than I do, I'll take direction from you on this one. Labeling items seems easy, but In which way to label them to work for blind people is not clear to me. Are there any resources for non-blind people to be able to test apps for accessibility in this way? |
|
Hello! |
|
Thanks for reminding me of the subject! |
|
Thanks for this! |
|
Hi. I'm another blind Prusa user and have been using a Prusa I3 MK3S for a little over a year now. I agree with the issues raised. Since it uses WX, it's possible as a start to make the controls readable. Right now, I'm using Object Nav with NVDA to figure out the controls. In many cases, I need to use other slicers since they work a little better with screen readers, but it would be ideal to use Prusa since there are a number of useful features that other slicers don't have. I'm also an accessibility analyst and would be happy to lend any help I can. |
|
Does the console version of prusaslicer work better with screen readers? By console, I mean command-line interface. IIRC, a user can create a .ini file with all the desired settings, and use it to slice, without ever needing the GUI. Also, I think the settings can be sent as arguments to the CLI. Would this be a useful workaround until the full GUI app is accessible? |
|
Yes, console version is accessible and a reasonable, but not ideal, workaround. I have looked into GUI code and have some conclusions, will write about it more after some testing. |
|
I agree that the console version could be a workaround, but far from ideal.
This is going to make the product useable only by the most technical users. Most people won’t want to learn the command line, how to set up the ini file, etc.
|
|
So many slicers have this problem. It would be amazing if one of them stepped up and fixed the problems. |
|
The problem requires much more research, because the screen reader clearly cannot see the labels being created. Setting a label for specific items works, but duplicates the graphic information. However, I cannot say why the actual labels do not end up in the accessibility tree, I have yet to test this. |
Could you please recommend a tool to inspect the accessibility tree? We are using wxWidgets UI library, which wraps around the system specific UI toolkits (Win32 on Windows, Carbon on OSX, GTK2/3 on Linux). Win32 is the worst offender of the three in regard to performance, which is realy, I mean really bad. We may need to get rid of wxWidgets / Win32 from at least the Plater side panel. We may pick Qt or imGUI, the first may be quite good in regard to accessibility, while the latter does not take accessibility into account at all. |
|
Dear ImGui seems like it would be a better choice, long-term. From a few GH issues I was reading through, I see that the dev(s) have their eye on the exact accessibility issue described here. IMO, adding the functionality to imgui or waiting for it to arrive would be better than hauling around the qt boat anchor. Please please please don't port to Qt lol. |
|
Any movement on this? I'm now using Prusa Slicer 2.5 and all the same issues exist. |
|
I tried many changes, tests and tries but could not find any workaround. I do not know WX too well but it is typically accessible, so some kind of mistery is going on here. |
|
We take your requests seriously. We had two totally blind people visiting us around two weeks ago. It was certainly an interesting and inspiring meeting. One of the two guys does amazing things: He designs tools, education tools and games in OpenSCAD, prints them on our printers and he manufactures them and caters them to a local shop fulfilling the needs of Czech blind community. I think the two guys explained us the needs of fully blind users very well. They also claim that every blind person they know is using Windows. Any of you is using Linux or Mac? Are all in this thread totally blind? Or is somebody partially blind? We keep your needs in mind, however we all have a load of other work to do. Let's see where your needs will fit in. @lukasmatena did some preliminary investigation of supporting ImGUI & screen reader on Windows. |
|
Exactly what I do as well. :) But back to topic, I am completely blind and confirm the issue on Mac and Windows. The problem is that it's really hard for me to pinpoint the cause. On both Windows and Mac, the screen reader uses a window hierarchy to interpret content. Let's take a textbox, we should have two controls: a label and the textbox itself. Sometimes it happens that the screenreader is unable to determine that the label belongs to a text field. Then the field is unlabeled, but the label itself is detected as a control in the hierarchical navigation or, simply, from the reader's console. |
|
Another one of those pesky visually impaired peeps here. I haven’t purchased a printer yet but have been downloading and attempting to use different slicers before I make my purchase. I am not totally blind as I do have some very limited remaining vision. I found that Cura seems to be quite functional on a Mac using voiceover. I don’t have a printer but I could go through all the setup, buttons, drop-down menus, etc. I also downloaded a printable and played with it a little. Bambu, and Prusa slicers are a no go on Mac using voiceover, which is weird as I thought they were all based on Cura? My use case may differ from other blind users as I use a 50” monitor, full magnification, a trackball, and hover text (which magnifies on top of the already magnified screen for super magnification which I still can’t read and also reads what’s under the trackball pointer) on Mac using voiceover (same on Windows with nvda but I had to switch over to the dark side of Apple with my vision loss as they have nailed accessibility and windows is just so buggy). I grew up using a pc and mouse and never got into all the shortcut commands after vision loss. In going to a foundation for blind I found that many older people find the ease of access much simpler on Apple products. Younger people that are going back to work or school are more likely to run windows as the jaws program (paid and not open source) for the blind and visually impaired is what’s more widely accepted in the corporate and professional realm. |
|
Hi! I believe I have found a solution. In terms of accessibility, WX predicts labels to be created immediately before the controls that apply to them. BTW. Issue duplicated by #10708 |
|
@dawidpieper Thanks for the offer. I am sorry, but I am not able to tell whether a PR that does not exist yet will or will not be merged. The wxWidgets code is quite fragile and it is very easily broken on some of the supported platforms, so it would really depend on what the changes would be. In general, we are reluctant to merge big changes. |
|
I totally understand that. Of course, I am ready to help solve any problems that may arise. |
|
I know for a fact there are more users than what is represented on this issue thread. Any help with this would be greatly appreciated!Sent from my iPhoneOn Oct 23, 2023, at 2:01 PM, Dawid Pieper ***@***.***> wrote:
I totally understand that. Of course, I am ready to help solve any problems that may arise.
I understand that blind people are a minority, but even the comments here indicate that there are a few of them and it would be nice if Prusa expressed interest in the accessibility of its services.
Either way, I am ready to undertake such work and consultations during it, also to make sure that nothing is broken elsewhere on any platform. But, I admit, the changes would probably be relatively deep. Although not in WX itself, of course.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>
|
|
Not something I have bandwidth for, but there are definitely quite a few users in See3D's network who would greatly appreciate some fixes here. |
|
If Prusa is not interested in making their software accessible for blind users we could think about a fork. But unfortunately I don't have time to make it up to date every upstream release. :( |
|
Hello Dawid and others.
We are taking the issue seriously, however we don't have the resources for
such a complex topic now. However there is a UI research lab here in Prague
that I used to be associated with, that may help us to look into it in the
long term, maybe by assigning the topic as a master or bachelor thesis. I
have already contacted them.
Vojtech
čt 26. 10. 2023 v 18:45 odesílatel Dawid Pieper ***@***.***>
napsal:
… If Prusa is not interested in making their software accessible for blind
users we could think about a fork. But unfortunately I don't have time to
make it up to date every upstream release. :(
Would be nice to have a clear declaration on this topic.
—
Reply to this email directly, view it on GitHub
<#7595 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABMPSI4P3BZ5IFBYWDKMNMTYBKHULAVCNFSM5KWLKGF2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZYGE2DQMRTGU2Q>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@bubnikv Were you able to find any students willing to work on this issue? |
|
Were you able to find any students willing to work on this issue?
That takes time, sorry.
st 8. 11. 2023 v 16:31 odesílatel SavageGarrett ***@***.***>
napsal:
… #7595 (comment)
<#7595 (comment)>
@bubnikv <https://github.com/bubnikv> Were you able to find any students
willing to work on this issue?
—
Reply to this email directly, view it on GitHub
<#7595 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABMPSIZ6CTGN5EIPFQI7D5DYDOQUPAVCNFSM5KWLKGF2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBQGIYTENZXHA3Q>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I have written minimum accessibility for PS, tested with NVDA on Windows. |
|
Yet another regress, #11749 . I am very sorry to write this, but I am currently completely disappointed with the actions of Prusa Research. I fully understand that a slicer may not generally be accessible software. I noticed this in 2021, but I completely understand that correcting it is not a priority. |
|
Hi one more blind user who is wanting some movement on this pleas. Pleas take people up on there offer of help. |
|
Hi I work with a lot of visually impaired students teaching them programming through 3D printing and OpenSCAD with Prusa mini printers. We use CLI as a fully accessible version and the GUI with keyboard shortcuts and profiles that I (sighted) set up that work for most models while students are still getting the hang of the cli to get them excited about printing faster. Would love to see @dawidpieper PR merged or this issue considered there are a bunch of students (we worked with over 1,200 BVI students from kinder to 18+ last year) who would appreciate having the independence and autonomy of screen reader access without all the background knowledge required to use the CLI. Also @bubnikv, Prusa would then be the first fully accessible GUI slicer (something that has been wished for for so long) ... I am happy to showcase some students work with you all and I am sure they would love to talk to someone on your team to share their work and tell you how much using your printers to create independently has meant to them! |
|
This has recently become a much more serious issue. In version 2.7, keyboard navigation in the preset drop-down is completely broken. If you try to arrow down to a preset, it doesn’t actually change in the software. Fairly sure it still works with a mouse, but can’t check.For example, try changing the material type using the preset drop-down using only the keyboard. When I do this, pressing the export button still shows generic ABS in the file name even though I said it to PLA.Sent from my iPhoneOn Dec 29, 2023, at 10:03 PM, funkonaut ***@***.***> wrote:
Hi I work with a lot of visually impaired students teaching them programming through 3D printing and OpenSCAD with Prusa mini printers. We use CLI as a fully accessible version and the GUI with keyboard shortcuts and profiles that I (sighted) set up that work for most models while students are still getting the hang of the cli to get them excited about printing fasting. Would love to see @dawidpieper PR merged or this issue considered there are a bunch of students (we worked with over 1,200 BVI students from kinder to 18+ last year) who would appreciate having the independence and autonomy of screen reader access without all the background knowledge required to use the CLI.
Also Prusa would then be the first fully accessible GUI slicer (something that has been wished for for so long) ... happy to showcase some students work with you all and I am sure they would love to talk to someone on your team to share their work and tell you how much using your printers to create independently has meant to them!
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>
|
|
To add some additional info to this, it seems that many checkboxes in the app are being identified as buttons instead of checkboxes. The buttons also have no labels, so a screen reader cannot identify their functions. |
|
I'm an accessibility expert and the lead developer of the AccessKit library. I can't dedicate much time to this specific app, but perhaps I can steer others' efforts in the right direction. I have a question for the Prusa team: I see that the application uses a combination of wxWidgets and Dear ImGui. How does the team decide which toolkit to use for each part of the UI? In the long term, is use of Dear ImGui likely to increase or decrease? If it's likely to increase, then maybe a good first step would be to integrate AccessKit with Dear ImGui (or a fork of it). |
|
I'd also like this fixed please. Thanks :) |
|
There's a simple workaround as I found for comboboxes, just navigate with arrow keys and press enter twice. |
|
I think it's time for a little recap. The issue is sad because I run an organisation that has set itself the goal of promoting the use of 3D printing for the benefit of blind people. We are active in Poland and are starting to cooperate abroad as well. We create materials for schools for the blind, everyday objects, mock-ups, board games, but also such small and important things as Braille door signages for offices. I myself am a blind person and I design our models in OpenSCAD, I also operate 3d printers, and this to an extent that I think is quite advanced, because whether it is installing Revo hotend or replacing a faulty fan or motherboard I personally can achieve it without help. So it is all the sadder for me when software gets in the way. Anyway, I give you the recently updated version of my Pull Request. Limited accessibility and very much a workaround, but it's better than the origin. I've added labels to text boxes, and checkboxes have an X when checked. This could be done better, but given Prusa Research's attitude I don't see much chance of that unfortunately. |
|
This is going to be a long one, but there is no way around it.
If you are suggesting that we decided to switch to custom controls after we saw your pull request, you are overestimating our development capabilities. The decision to do it and most of the work was done long before that. One of the main reasons to do it was to allow scaling of the controls properly, which by the way was done to help people who can't read them. This means people with less severe vision problems and also most of older people. The people who complained about this are missing in your "little recap".
The real problem is that the needs of various people are often so different that it is difficult to please them all. This is not just about accessibility issues, but with everything, really. We are of course trying to prioritize tasks based on how many people would use them, which is where the category impression comes from. And although it must sound hurtful to you (which I am honestly sorry for), most people care about other things than how a screen reader reads it. It is difficult to balance in the finite time we have for development. The whole thing is made even worse by the fact that the software is multiplatform and it is based on technologies which impose additional constraints about what is reasonably possible. As was already mentioned in this thread, we did in fact meet with a (completely) blind person who 3D prints. I realized quite a lot of things during that meeting. My key takes from it (keep with me, I have a point to make):
The last point was the real eye-opener. There are many features in PrusaSlicer that these people cannot use. For example, it is pointless to make the dialog related to painting features accessible to screenreader, because these people cannot use that feature anyway. This one sounds obvious, but there are many more features like that. In fact, it may be better to have these features NOT accessible to the screnreader at all (which means they are effectively removed from the UI), because there is no point in presenting a feature that a person cannot use. I realized that the PrusaSlicer that they are using is more similar to the menu on the MK3 printer, and that they mostly load the model, select a profile, tweak few of the parameters and slice. They don't use place on face, paint on supports, they don't see notification warnings (they are currently unavailable to the reader), and so on. I also understood that these people are used to keep a location of everything together with its existence, and that navigating the "MK3 menu" is in certain sense easier for them than for me, because they never have to look for anything. What I am trying to say is that screenreader accessibility is one thing, but I am worried that the logic of the UI will still not be optimal, and the people will still be disappointed and need further changes. PrusaSlicer was made to be used by people without disabilities, with the assumption that the user can see and that he or she use a mouse. Trying to make it accessible properly will mean compromises for both groups, and current limitations will make it painful and tedious to do. We might hack it together somehow (similar to what you do in your PR), but from my current point of view, it will be suboptimal anyway, and it may easily become a maintenance burden, because it will impose further constraints on what we can or cannot do. Right now it is about system vs custom controls, but I am sure that it would become a general issue. Now an idea that I had recently. From what I understood so far, blind people basically only use basic features which are also available through the command line interface of PrusaSlicer (which was mentioned above by @n8bot), and they do not really use much of the UI. Maybe instead of hacking and bending the current UI to serve all, it might be feasible to create a much simplified PrusaSlicer frontend, which would only present the features that make sense to present, and which would just use PrusaSlicer backend though the command line interface (or by linking to the libslic3r module). This frontend could be designed the way it makes sense for the target group, it might be made using a UI toolkit which has good accessibility support by itself (whichever that is), it would focus on getting Tab order right and so on. @mwcampbell @dawidpieper |
|
Hi @lukasmatena ! It is true that a blind person does not need to paint supports in a slicer, but many other tools not available through the CLI are already useful. For example, I very often use different settings for different heights of the model, whether it's simply to change the height of a layer, to enable the ironing of specific layers or to print with different nozzle diameters. As for the interface changes, my guess is that the decision was made long before my pull request, but probably not before this issue was opened. And even if it was, again accessibility issues were not taken into account. Well-thought-out accessibility is characterised precisely by the fact that, at some point, no one has to create dedicated code for one or another minority group, because this UI is already accessible at a basic level and, at most, minor tweaks are needed from time to time. |
|
The problem at this stage is comboboxes and, to a lesser extent, checkboxes. Then we can start to build smaller bricks, like correct handling of the tab key, jumping between tabs, the toolbar, but these are already smaller things to introduce by the way, while we would have a good base with an accessible GUI - ugly because ugly, but usable. |
|
To be frank…. Not everyone uses a mouse. In fact, most younger folks might not even know what a mouse is! Ha. Tab navigation or command key shortcut navigation would most likely be beneficial not just to the blind and visually impaired. I do agree that while a person such as myself might not be able to benefit from every single option within the slicer, who exactly is qualified to make the decision of what would be of benefit? Realistically, most people think oh you’re blind, you’re incapable of doing anything, why bother. It has even been echoed in here. It’s very disappointing. I was sighted my entire life, up until a couple years ago (I’m now 49). I also often (jokingly) bragged about being able to just about anything blindfolded with one arm tied behind my back. Now that I’m in that position, I’m astonished with all the things I am unable to do solely due to the lack of a simple tool. A tool that quite honestly, in this day and age, should not be an afterthought. Heck, a lot of programs even have a built in accessibility checker to verify that a document, spreadsheet, chart, graph, etc. will work with accessibility features. Even ai can generate code and scripts to help devs comply with accessibility standards. In any case, I truly feel the disappointment here and recognize that I shouldn’t hold my breath in hopes of a solution. I do not expect everyone to jump through hoops to make things work for such a small group but I will share an example of what I call stellar support. I have been vested in smarthome gadgetry heavily before vision loss. I have a smarthome hub that had an interface with similar issues as Prusa slicer. It just did not work with screen readers. The manufacturer is much smaller than Prusa research I’m certain, but here is the difference. Firstly, they acknowledged that I was the first blind user they have encountered and quickly offered to help me out temporarily by FaceTiming me and then connecting remotely to fix some issues for me. Then, months later, they contacted me out of the blue and asked if I would like to try a beta os that they voluntarily came up with using in house devs as well as obtaining assistance from a local university. That beta release worked almost perfectly and only needed a few adjustments but is now fully functional with screen readers. Truly a remarkable outcome, much different than oh well, there’s only a couple of you, you couldn’t possibly be able to use any of these functions and it’s just not worth our time. |
|
@aBlindReefer Here I have posted a compilation of PrusaSlicer for Windows with basic accessibility patches. I invite everyone to check it out, it's very circuitous, but maybe it will help someone else. :) |
|
Hi @lukasmatena
I understand there are competing priorities, but to assume that these fixes we are asking for only impact a small subset of people would be incorrect. This is because accessibility improvements can benefit more than just a specific disability group. For example, ensuring controls are properly labelled not only makes it usable for screen reader users but people who use voice control and it can make for cleaner more understandable code for your developers. Likewise, ensuring full keyboard control where controls can be accessed with tab/shift-tab and keyboard shortcuts not only makes it possible for someone who is blind to use the app, but it benefits those with mobility challenges who are using alternative input devices, and anyone not disabled with a workflow where they prefer to use partial or full keyboard access. If we take a step back and ask why there is a small subset of people that's engaging in 3d printing, it shouldn't be a surprise that inaccessible software would be a major factor that contributes to it. It's a classic chicken and egg problem where the company is seeing only a small subset of users with disabilities using their product and thus feels that accessibility isn't a priority. However, if accessibility became a priority, I guarantee that you would see more disabled users using the slicer. Many schools and libraries are purchasing 3d printers and want to make the process as accessible as possible to everyone which of course includes blind users. They aren't doing this just because it's the right thing to do, although that should already be a compelling argument, but also because there are regulations about purchasing the most accessible product so that they do not create more barriers for users with disabilities. The only reason why you are seeing several of us who are blind asking for fixes is because we are the people with more advanced tech skills who are willing to put time and effort into figuring out workarounds and engage with you to discuss solutions at a more technical level. If 3d printing is truly for everyone which is what 3d printing companies like yours is betting on, we shouldn't expect that all blind people will slice with the command line and pay $150 just to have access to basic GUI accessibility.
I think that gets into the territory of making assumptions of what blind people can and can't use. While features like painting on supports is currently inaccessible, there's no reason why with some creativity, we can't make it accessible in the future as newer technologies come out like tactile image displays where a blind user can feel the graphic and draw on it using a finger or stylus. The Graphiti which was released not too long ago has this capability. Discussing whether it makes sense to make those features accessible right now though is irrelevant until there is basic screen reader support. As for developing a separate app/front end, this was a common idea popular in the 90s and 2000s. People realized very quickly that maintaining two separate versions took more time, energy and money than making one single app to follow general universal accessibility principles with tweaks through the development cycle. As a blind user, I sometimes change layer heights, infill, material types, enabling supports, adjusting model orientation and spacing, etc. As was mentioned, some of these features aren't accessible through the CLI and without access to opensource slicers like yours, we won't be able to take advantage of newer features like layer ironing or use AI to describe how the model looks on the screen while making adjustments. We know that accessibility takes time. We're not expecting a fully accessible version or that even basic accessibility will b achieved today, but our hope is that Prusa will collaborate with us to make the slicer more accessible through strategic fixes like starting with control labelling and tab order. Not only will fixes and improvements positively impact access to your printers but, because it is forked by other companies, there's a chance that any accessibility fixes will trickle down and make their app more usable which will make the entire ecosystem a more accessible and welcoming space for everyone. |
|
I think @kayatli made an important point that we expressed, but probably it could be missed. |
|
Linking an interesting story below. The sound of effort this person (who is blind) put into this seemingly simple project is just nuts. Sure would be nice not to have to go through all these hoops! |
@dawidpieper, We merged your PR with last master and made a minor improvements. |
|
Thanks @YuSanka for finally looking into this. Will look into the editboxes issue. |
|
@YuSanka Would be nice if you could provide sources to check what's the issue now. |
|
@dawidpieper, Thanks for testing. |
Version
2.4.0
Operating system
Windows 10/11 and Mac Bigsur; Linux to be tested
Behavior
Expected Results
Blind users should be able to reach all interface options, all controls should be properly labeled and navigation using Tab Key should be possible
Actual Results
Application is inaccessible and nearly unusable, tested using NVDA Screenreader
I, as a blind person, am able to use this app only using OCR and chierarchical navigation, which are extremely advanced techniques. For an average blind user this program would be completely unusable.
The program uses a lot of graphics (for bed visualisation, for example) and making it completely accessible requires an enormous amount of commitment, but basic accessibility should be easier to achieve. The most important steps include:
While I know that this may sound unbelievable that blind people will get involved in 3D printing, I am an example that it may happen.
If you are interested in enabling the blind to use the program, I also offer my help both as a tester and a programmer.
The text was updated successfully, but these errors were encountered: