Add labels/aria tags to UI elements

[hidwood]

Requested feature:

The UI should be updated with tags that give assistive technology, such as screen readers and magnifiers, understandable and focusable content that is reflective of the page. Aria(Accessible Rich Internet Applications) labels can be used for this purpose rather than adding traditional labels, as they would most likely interrupt the UI design and add extra clutter. This would allow for a much easier user experience for those that require such assistive technology, as well as better conforming to web content accessibility guidelines. Aria Live regions can also be used to alert users of assistive technology of notifications and important events, such as a component needing updated in the update manager or Klipper shutting down due to an issue.

Solves the following problem:

When navigating Mainsail, many elements are completely unlabeled for screen-reader users. This includes many buttons on the dashboard, many of which are not clearly obvious to a screen reader user as to their function, with others obviously belonging to increment and decrement buttons on various fields. Every page, notably the connect printer dialogues and macro screens, have several buttons whose purpose is unclear. There are likely many more examples but given that it is not necessarily feasible to run mainsail as a screen reader user now, they have not all been catalogued, however it may be noted that almost every button, barring the send button in the console, lack labeling.

Additional information:

Official vue.js accessibility page:
https://vuejs.org/guide/best-practices/accessibility
The Web content Accessibility Guidelines:
https://www.w3.org/TR/WCAG21/
https://www.w3.org/TR/wai-aria-1.2/
https://www.w3.org/WAI/ARIA/apg/
Examples of screen readers, magnifiers, and other automated tooling is available on the vue.js page linked above.
I am not a particularly skilled frontend web developer, and thus have relatively little idea how much effort this may take, however I fear that it may be significant. I would be glad to help in any way to rectify this, as, being a completely blind maker, having another option other than OctoPrint that can talk to Klipper would be fantastic, especially one as capable as Mainsail.

[meteyou]

Thanks for your request! I think we have a lot todo with that. Can you also write a short "roadmap" which panels/paged would be the most important we should begin? I think we will need multiple steps to implement/fix something like that and we cannot do this in 1 step.

[hidwood]

I sincerely apologize for not providing one earlier; your request makes complete sense.
In terms of prioritizing features for accessibility improvements, I would recommend starting with panels that are critical for controlling and operating the machine. For example, the Dashboard should be a primary focus, as it is fundamental to core functionality such as controlling and monitoring temperatures, fans, moving the toolhead manually, etc.
The Console already seems to work relatively well, with features like a labeled Send button in place, so it likely requires minimal changes. Following that, the Files view should be prioritized, as managing files, starting prints, and adding files to the job queue are essential tasks for most users.
The Interface settings also appear to function effectively, likely requiring little to no adjustment. However, the Connect Printer dialog could benefit from improvement, as it is functional but not entirely intuitive for users relying on assistive technology.
Lower-priority views would include features such as the G-code Viewer, Heightmap, Timelapse/Webcam support, and History view, as these are convenient features rather than essential tools for operation. Please note that I am using the tabs and .vue files for my naming reference, as I seem to have somehow broken my Moonraker setup. If you require more granular panels within the specific views, I would be happy to provide an evaluation of those as well, but it may take a day or two to get up and running again.

[lnorton89]

This absolutely needs addressed--why some elements display tooltips while others do not is sloppy and not acceptable for software this mature. Every element on the page that controls the software should have a tooltip.

[meteyou]

This absolutely needs addressed--why some elements display tooltips while others do not is sloppy and not acceptable for software this mature. Every element on the page that controls the software should have a tooltip.

At first... We all do this in our free time and nobody get payed for it. So if you think you have to be aggressive and post down votes, feel free to implement it yourself in your free time for free!

Too many tool tips will also break the UX and tool tips itself have nothing Todo with this FR. Tooltips are not for screen readers!

[rackrick]

I agree with meteyou... no need to get angry. We're doing this in our free time and don't get any money for that. Even if mainsail is pretty mature right now. Most of the crew probably has little to no expierience with screen readers. At least I don't have any.

@hidwood Do you think you would be able to test changes when we provide you a preview build?

[dw-0]

This absolutely needs addressed--why some elements display tooltips while others do not is sloppy and not acceptable for software this mature. Every element on the page that controls the software should have a tooltip.

@lnorton89 Did you pay for Mainsail? If yes -> you were scammed.
If not -> Be grateful that this software remains free of charge, free to use and open source. So please spare us with your entitled behavior, it is not acceptable and you won't change anything with behaving like that.

[hidwood]

@rackrick and @meteyou I would be open to testing and evaluating any changes, I really do appreciate how seriously this is being taken and would be happy to assist in any way I can.
"This absolutely needs addressed--why some elements display tooltips while others do not is sloppy and not acceptable for software this mature. Every element on the page that controls the software should have a tooltip."
I hate to reiterate what others have said, but there is little reason to be hostile in a situation like this, especially given the incredibly daunting nature of such a task and especially because of the free and open-source nature of the project. Being willing to improve the accessibility and usability of software for those with relatively niche disabilities is a kindness that is rarely afforded, and it seems better to choose to accept and nurture any effort made, rather than bash it because it currently does not meet some arbitrary standard.