Hi Team, we are looking for a11y in our application. We got to know GoJS 3.x providing accessibility support. I need help with that.
Thanks
I assume you meant upgrading to GoJS version 3, from a previous version.
The WCAG guidelines are meant for developers like you to make web pages/apps more perceivable, operable, understandable and robust.
That is not something that any diagramming component can provide out-of-the-box because implementing those guidelines should be different for each app. Only you know what it is that your diagram is really showing and how it should really be used.
So the Accessibility sample is just an example of the start of accessibility support. Your app will need custom behaviors to best help users understand and use your diagram, depending on the semantic relationships that the diagram presents and the information provided by the nodes and links and groups.
Hi, @walter We are looking to explore a11y for loops nodes, links & interactive elements(context menu). Does gojs(v3.x) a11y supports by default navigations for those?
No – again, what you would want to do would depend on the semantics of your diagram/graph.
Okay. But we have a usecase where we must navigate to inner html/node/interactive elements. As shown in the picture below, if we add a11y, we can navigate between the nodes(which is highlighted in the picture’s last row) but our usecase is to navigate within the node ex: to email, phone which are interactive elements in a node. How can we achieve this using gojs a11y?
You would need to write custom code to do it. Probably you don’t want to iteratate over the Node’s GraphObjects themselves, but use the Node data in some meaningful way.
As a basic example, maybe you want to output information about the node somehow when a user presses a key like ‘x’:
myDiagram.commandHandler.doKeyDown = function () {
// method override must be function, not =>
const diagram = this.diagram;
const e = diagram.lastInput;
const k = e.commandKey;
if (k === 'x' && diagram.selection.count !== 0) {
// do something with the node data
const data = diagram.selection.first().data;
console.log(`the Node's key is ${data.key}`);
console.log(`the Node's color is ${data.color}`);
// or any other data.property
} else {
go.CommandHandler.prototype.doKeyDown.call(this);
}
};
This is close to what the Accessibility sample does, except that sample describes surrounding nodes instead of the node itself. But there’s no reason you cannot modify it or add to it to describe the node itself. (Note this sample also uses the letter x for something already)
In the case of the org chart sample, you’d want to look at data.name, data.dept etc. These (whichever are relevant) are specific to your app.
@simon Do these code changes need v3.x upgradation? or can we do it with v2.x itself?
These particular customizations can be done with 2.3.x versions, at least.
Okay. What will we get in terms of a11y if we upgrade to 3.x? Currently, we have customized accessibility but we are facing focus issues. Undo/Redo/Delete is not working as the focus is shifting from diagram to node.
It’s difficult to know precisely what changes will be in your app, there are a number of new features which may or may not be relevant to you. From our point of view its always good to update to the latest major version so that if you do encounter a bug, we can fix it (or at least be sure it hasn’t already been fixed).
In terms of a11y we may have made minor changes to the library in order to create our accessibility sample, but I cannot recall any. So you probably don’t need to update.
You may want to review all changes:
Okay. Currently, we are implementing a11y using hidden buttons & navigating accordingly. Due to the hidden button, the focus is shifting from the diagram/canvas to the hidden buttons. Can we get rid of the usage of hidden buttons & use **myDiagram.commandHandler.doKeyDown = function () {
// method override must be function, not => ** to implement custom a11y @simon ??
Could you please describe more precisely and thoroughly exactly what functionality you want to implement in your app in order to replace the use of the mouse/finger? It would help a lot if you provided screenshots showing before and after for each input event.
We are looking for a11y for group nodes & interactive elements.
As shown below, the image:
Can we achieve this using an a11y extension ?? At least by overriding the existing functionality provided as part of AriaCommandHandler ?
Yes, I believe so. But it isn’t clear to me exactly what keyboard commands you would want to implement, nor what kind of highlighting you want to do. That’s why I was asking for a more detailed description of the keyboard input events.
But the general answer is “yes”, by implementing various keyboard commands whose behavior is dependent on the current state of the navigation and of the diagram.
@walter We want Arrow Keys for our scenario & we are looking for navigating groups, nested nodes & and interactive elements i.e. ContextMenu.
I recommend copying the extension into your own project and modifying it to suit your needs, as we recommend for any of the extensions which one might use that need customization.
Thanks for the confirmation @walter
We have a few questions on how A11Y works with the extension:
Query
One more question. How can I iterate through a GraphObject/Interactive Elements?
As shown in the below image if I gave findSubGraphParts() on the Group node it’s giving me only nodes & links but not any GraphObject/Interactive elements(In our image its expand/collapse icon)
First, please understand that “accessibility” isn’t an entity with agency. It’s a characteristic of an app, not something that does something.
Second, I hope you see now why the concept of accessibility must be tailored for each specific app. The code that we supply cannot know which node you want users to start from, nor which nodes you want users to go to next, nor which non-Node & non-Link (i.e. non-Part) objects to be able to navigate to.
There might be any number of buttons in your Node (or in your Link!), but we can’t know what you want to be able to navigate to and in what order and under what circumstances. In your case, when the user is focusing on the “Zeta” Group, which command should change focus to the “Eta” Node, which command should change focus to the “SubGraphExpanderButton”, which command should change focus to which Node that follows “Zeta”? And might users want to focus on the Links?
So use the Accessibility sample just as a framework for defining the behavior that you want in order to support accessibility for your users. I recommend that you either accept or reject each bit of functionality that it offers.
