Workflow logical sequence and symbols are not accessible for blind and visually impaired developers.

[hamidrezaabroshan]

Describe the Problem

I'm a blind developer (backend java) and I'm using screen readers to work with computers.When I open a bpmn file, I can click on the boxes and see it's details but I can not understand the logical flow of the app through boxes because my screen reader only reads the name of the box and can not understand bpmn symbols that relate boxes together and shape flow of the app.You can test it with a free and open source Nvda screen reader app on windows. It's portable and easy! just download and press enter and test the accessibility of the bpmn models.If possible, after opening a bpmn model, try to close your eyes and compare the information you hear with the information you just saw on the screen.You should understand the logical flow of the bpmn model and be able to say which flow starts first, which flow relates to another and ...

I'm here for any support for testing the accessibility and suggesting fixes.

Expected Behavior

• Diagram is readable by screen readers (i.e. Nvda)
• Diagram can be navigated / discovered via keyboard shortcuts

---

Depends on https://github.com/bpmn-io/diagram-js/issues/567

[nikku]

Hi @hamidrezaabroshan, thanks for opening this issue.

To share my perspective on the topic, accessibility on (BPMN) diagrams involves two core things. Given a certain element:

• Read it out (with all required context, i.e. label, documentation but also, potentially including implementation details)
• Discover and follow along the flow on forward or backward, with the keyboard (i.e. navigate from a Task to an outgoing SequenceFlow to the connecting ExclusiveGateway).

We need to properly support this at the core and my hope is that this diagram-js issue already captures the gist of it. Could you cross check the expected behavior we've captured?

My hope is that we did fully capture the problem domain. I'd be glad to get your feedback here.

[hamidrezaabroshan]

Thanks @nikku for your attention to this topic. I read the mentioned issue and I think that covers most of my needs, but I'm consulting some of my friends who are using screen reading softwares and getting their comments. I'll ask them to reflect on this issue. For now, I have general note:

1. Screen reader users mostly use keyboards and everything should be navigable with system focus E.G, you should be able to navigate by arrow keys and tab or shift+tab.
2. consider using shortcuts to navigate between flows, getting more info, and their symbols. Regards.

[nikku]

Thanks for your follow up. You're feedback is highly appreciated!

consider using shortcuts to navigate between flows, getting more info, and their symbols.

How do you generally deal with shortcuts? Is there a way simple way for screen readers to discover shortcuts (beyond the basic ones you've mentioned)? Or do you read the documentation upfront?

Screen reader users mostly use keyboards and everything should be navigable with system focus

How would you deal with the fact that multi-selection is possible in our tool, and system selection may not support it? I guess a strategy would be to only make the first / primary selected element selected, from the browser / OS point of view.

[nikku]

E.G, you should be able to navigate by arrow keys and tab or shift+tab.

Given that we're dealing with a graph here and not a sequential document this may be hard to accomplish; in a graph, there simply does not exist a canonical next and previous element in many cases.

[hamidrezaabroshan]

Thanks @nikku, I 'll answer the ones that I know and these are my initial solutions but may not be the best. 1. "Given that we're dealing with a graph here and not a sequential document this may be hard to accomplish; in a graph, there simply does not exist a canonical next and previous element in many cases."

Graph nodes could be navigated by up or down and by pressing the write arrow this node will expand and User can explore it's childs and by pressing the left arrow key this node will collapse and the user can see other nodes. You can test something similar by tree view in windows with a screen reader. Note. vertical or horizontal layout does not affect Screen reader users because it can confuse the user whether the layout is vertical or horizontal. A Similar way is to show only the first parents or the root nodes for screen readers and by pressing the enter key on each of them, the child's will appear and by pressing Esc key the user can go back to parent roots and so on. Like a web menu that by pressing enter on them it will show it's sub menus.

[hamidrezaabroshan]

2. @nikku: "How do you generally deal with shortcuts? Is there a way simple way for screen readers to discover shortcuts (beyond the basic ones you've mentioned)? Or do you read the documentation upfront?" For mnemonic keys, Screen readers will extract and informs users automatically E.g, file starts with F and New in File menu, starts with N and mnemonic key will be alt,F,n.For accelerator keys, E.g ctrl+alt+j,  in windows Guis they will write the accelerator key in menu or button label and in Web you can use alt text to inform your user.Also, please study about aria tag for accessibility>> with tag, you can send accessibility info to screen readers.

"How would you deal with the fact that multi-selection is possible in our tool, and system selection may not support it? I guess a strategy would be to only make the first / primary selected element selected, from the browser / OS point of view."First I need to say because camunda modeler is actually a web app, most of it is accessible by default and you do not have to do complex work oor heavy change in this app.I write this info to make things more clear and don't think that all this info needs a change in UI.I think just by providing some accessibility info this app will become fully accessible.

I usually test if I can select one or more elements if I need to.Standard components like checkbox, listbox,  buttons are accessible by themselves. but you should inform your screen reader user that this element is selected if you are using a custom component E.G, if you use an image box that can be selected by pressing enter on that box, you can make it accessible by creating a standard checkbox beside that image or inform the user by providing accessibility info.E.G, if Screen reader user presses enter on a checkbox, Screen reader says the name of the element and "checked" and if he presses enter again, it will say: "unchecked"

[shadyar]

I have exactly the same problem. Please!, This bug should be addressed very soon. This problem greatly annoys blind programmers and limits their abilities.