WIP: Accessible Data Grid

MODX makes heavy use of Data Tables, aka "Data Grids", so an accessible data grid is important to a future accessible user experience. The current interface (2.x) hides features behind a right mouse click, making them only accessible to sighted mouse users with fine motor skills who are also technically literate.

Targeting a future version of MODX (4.x) and as part of recommendations I've drafted for the MODX Advisory Board, I've been working on a data grid component that is mobile, keyboard, and screen reader accessible. Would great appreciate feedback especially from experienced assistive technology users. There are issues labeled "accessibility" and "help wanted" on GitHub:
https://github.com/jpdevries/a11y-datagrid/issues?q=is%3Aopen+is%3Aissue+label%3Aaccessibility

Demo
http://a11y-datagrid.markup.tips

Screencast (4min)
https://vimeo.com/219314498

Source
https://github.com/jpdevries/a11y-datagrid#accessible-datagrid

Looks great!

I assume you plan to add sorting by some of the other fields (e.g., key).

Is it possible to add a little JS to allow right-clicking (for those of us who are used to it) without interfering with the accessibility?

Quote from: BobRay at May 30, 2017, 06:11 AM

I assume you plan to add sorting by some of the other fields (e.g., key).

Ya. Sorting is in the works. Keyboard shortcuts also.


Quote from: BobRay at May 30, 2017, 06:11 AM

Is it possible to add a little JS to allow right-clicking (for those of us who are used to it) without interfering with the accessibility?

Yes. The Eureka Media Browser does this using HTML5 Context Menus (Firefox only currently). I'm hoping by the time we see an all-new MODX manager HTML5 ContextMenus will be safer to use, but I also try and avoid putting anything behind them.



I think a lock feature would be interesting. Similar to how you can lock a resource, it would be nice to lock System Settings so only you could unlock, modify, delete them.

Still fairly experimental but adding accessible sorting. It isn't your familiar click-two-tiny-triangles feature, because that isn't very inclusively designed.

There is a radio group within the table head that allows you to choose a column to sort on. Since it is a radio group, it comes with all the implicit keyboard and screen reader friendly awesomeness. Down in the pagination controls, there is an option to change the Sort Direction. Originally sort direction was a combobox (select), but if there are only 2-3 options I think a radio group makes more sense as it takes 1 click to change an option not 2.

Sounds great. I like it when clicking again on the field selector reverses the sort direction (a la PhpMyAdmin). Clickable arrows are also nice if you don't want to scroll down to the bottom.

Quote from: BobRay at May 30, 2017, 08:17 PM

I like it when clicking again on the field selector reverses the sort direction (a la PhpMyAdmin). Clickable arrows are also nice if you don't want to scroll down to the bottom.

Yes I agree that is nice and expected. I haven't really figured out a way to make that inclusive yet, so right now clicking the column heads sorts it by that, and then down where pagination is there is the option to change the sort direction. There is also a keyboard shortcut (alt + up/down) to change sort order.

Eventually once I get to icons maybe I'll add a tiny "sort toggle" button to each column header.

I did sneak one power user feature into the "right click" menu. The ability to move a setting to another area. Imagine also being able to change a Resource's template that way. I think that would be nice.

I look forward to seeing the finished package. The speed is amazing.

One thing I really miss in the current Manager is stable, predictable element IDs for everything (e.g., id="pagetitle_caption", id="pagetitle_input", etc.). I don't see them as necessary for the grid entries (though it might be nice). But they'd be useful for the all the action elements. I mention this because I think it should be a policy to have them and integrate them into all the code from the beginning.

Not only do they give users and developers a handle to attach things to, they'd also be great for JS-based compliance/conformance testing.

Quote from: BobRay at May 31, 2017, 03:41 AM

I look forward to seeing the finished package. The speed is amazing.

Ya, it is pretty snappy. Would you believe me if I told you it hasn't even been completely optimized yet? With further optimization, and also with a future version of React (Fiber) it will be even faster.

Yes I agree naming should be as consistent as possible. I think some of the sloppy names just come from developers coming up with names as they code. When you are in programming mode you aren't always thinking of the most logical names. Working on consistent names and plain language sounds like something we could get the community to contribute to. If someone in the community put together a draft on how to handle such a project I'd consider sponsoring it and proposing a vote to the MAB.

The sloppy naming is an issue, but a much bigger one is the on-the-fly IDs that modExt generates, which can change at any time, not to mention the inline styling:



You have to examine the page in Chrome Dev. Tools or Firefox to even see them, because they don't show up at all in "View Source."

Quote from: BobRay at Jun 01, 2017, 04:24 AM

The sloppy naming is an issue, but a much bigger one is the on-the-fly IDs that modExt generates, which can change at any time, not to mention the inline styling:

Ah, yes. I think if we adopt an HTML-first process for the next manager we won't have that issue anymore. I feel we need to be very careful not to run into the same issues with 2.x just in another way. What I mean by that is, we shouldn't go all in on React, Vue.js, Angular, or whatever as we did with ExtJS in 2.x. At least not in "the core". As awesome as React is, if we shipped it in the core years from now we'd wind up with the same kind of technical debt we are experiencing now from ExtJS.

I've started working on a Progressive Manager DRAFT that aims to protect us from this technical debt while providing the creative freedom to enhance the Manager with whatever tools you like.
https://github.com/modxcms/mab-recommendations/pull/2

The community has long pondered "what JavaScript framework should the next Manager be built with. jQuery? Angular? React". I think the answer is none of the above. In fact, that DRAFT goes as far to suggest that the MODX core, should just be the MODX core and not even ship with a Manager interface at all. Rather it would ship with a few default "core packages". One that provides the Manager interface as semantic HTML and perhaps another to style that HTML and another to enhance it. This would bring creative freedom to the MODX manager itself and decouple the front and back end allowing them to be on their own release cycle. Currently front end contributors who would like to update the Manager interface have to wait for breaking changes to happen in the backend but if we decouple that would no longer be an issue.