Bryntum Support Forums

We are starting to see increased demands for compliance with accessibility standards from government customers. These demands spins out from the EU standard EN 301 549, which again builds upon W3C WCAG 2.1 recommendation.

Existing thoughts & measures
Now in relation to your UI components - in particular Gantt - have you had considerations and perhaps supportive measures to address specific recommendations from WCAG 2.1? If so, what are these?

While the recommendation covers a lot of areas, our main concern is that navigation, operation and all functionality should be executable/possible without the use of a mouse/pointing device.

Short Cuts
From the documentation I see that custom keyboard mapping is supported, which is makes it possible for us to implement a mapping for the functionality in use. That is great Perhaps you already have a recommended "standard" mapping?
https://bryntum.com/products/gantt/docs/guide/Gantt/customization/keymap

Tab & Arrow Navigation
What about standard navigation inside the app? In the online examples, for example https://bryntum.com/products/gantt/examples/advanced/, I find the tab and arrow key possibilities rather limited. I cannot tab into the chart itself - it seems to loop in the header section. I cannot use the arrows for 2D navigation either. Perhaps there is configuration that must enable such functionality?

In that example, tabbing navigates through the header, down into the toolbar and then onto the grid headers. Grids work as standard with cell to cell navigation based on arrows.

Yes, the user have to change from tab key to arrow-down when focus is on the first column header. That leaves some room for improving the navigational consistency.

What about the chart itself, how do you enter and navigate the objects by keyboard alone?

Tabbing between controls is natural HTML.

Arrow navigation within in a grid is an ARIA standard.

Navigating to a cell which contains a task, jumps down into that cell and focuses the task. When the task is focused, SPACE invokes the context menu, ENTER invokes the editor:

I am of the opinion that focused state should be much more visible and should be visible event when a mouse pointer has been used to achieve focus position.

I suggest that we need an accessibility theme which has these characteristics.

Thanks, I think you point it out well:

In my case I'm not navigating within the grid. I'm navigating the column headers - thus it is not obvious that the user should now be using arrow keys.

While not directly comparable, Microsofts Excel app and Googles Sheet app enables arrow navigation within the grid, not the headers.

I think the problem is easily fixed by having a tab stop in the first cell.

You video I think shows a great experience - one that I cannot replicate in the advanced example - I seem to get "focus-trapped" in the last column and neither enter or space works the way you describe.

Can you replicate the behaviour you describe here?

https://bryntum.com/products/gantt/examples/advanced/

I think you are right on the "focus visibility" point - One easily loose track of what is focused - at some point I event got a focus grid cell AND a focused object at the same time (not sure how that happened).

The two most critical test points of the WGAC recommendation is exactly about functional access via keyboard and avoiding focus traps (Level A, https://www.w3.org/TR/WCAG21/#keyboard). What is not clear to me is if these issues may be solved by configuration or if they have to be handled by you.

The column headers, are, according to the ARIA standard, just cells.

I was using the example page to make that video.

Seems like LEFT arrow from an event bar thinks it's jumping back into the grid from external, which means jump to the last focused cell there.

It should of course go back to the last cell in the locked side that is on the same row. We can fix that.

In Google Sheets, you cannot navigate onto headers at all. It seems they are not activatable items, where in a Bryntum grid, they are.

Also, once in the sheet, you cannot SHIFT+TAB back out of it into the toolbar again.

That sounds great. Will you set up the issue in github?

Why Microsoft and Googles would want to trap/capture the tab navigation is not clear to me. I am sure that is debated heavily somewhere else. Luckily we are not the ones to handle their accessibility issues

Both grids seem to support both tab and arrow keys within "the grid" though, which could also be a solution to the tab problem:
The grid (i.e. the list and chart in Gantt) as a whole only has one tab stop, which is the first column header and from there on arrow key navigation must be applied, which is not clear to the user.

A tabstop at the first cell would be a better solution to the issue though, as allows for a design that lets the user to tab into the chart area as next 2D zone.

Regarding your valid point about the ARIA standard, yes since the headers in Gantt provide functionality, they should be accessible. If the header do not provide functionality it should not be navigable by 2d means.

We see those points listed here with examples:
https://www.w3.org/WAI/ARIA/apg/patterns/grid/examples/data-grids/

Now (and this is the important part) - notice how they designed the second example (with sorting headers): first tab stop is within the grid cells, NOT the headers (just click somewhere above example 2 and tap away until you're in the grid).

So, The ARIA standard also say that you must consider each application isolated and make sure the design is ideal for common application. Like they show, we should lead the user to the main area (e.g. first cell) and not a "#" header (which does not provide functionality by the way).

In the second example, all headers are navigable cells: