Keyboard-enable all features for section 508 compliance and accessibility

[ygyg70]

Column sorting, hiding etc. doesn't seem to respect focus and keyboard interaction.
Is this a planned capability?

[PaulL1]

It is something we'd like, but not currently in the roadmap.

[ygyg70]

Section 508 compliance is a requirement for many software projects. As of today all ExtJS components support keyboard interaction. Would be nice to have an open source, modern, high quality alternative.

[PaulL1]

Yeah, we'd really love to have it too :-). I don't think it's overly hard, it's just a bunch of time to invest to work through all the permutations and handle them. We'd really welcome some assistance - the gitter channel is quite active, and there's a good first time contributors guide. Do you have to time to help out with it?

[ygyg70]

This is not my personal project. Will include that option when selecting framework and components.

[c0bra]

@ygoraly ExtJS has the benefit of being backed by a company so they can afford to tackle things like this. A small open source project really can only do what users are willing to contribute, and that's usually only the things that the users themselves need.

If enough people want the grid to be 508 compliant then someone will probably write it. The other option would be paying for it by funding for the issue on bountysource or something like that.

[rajulkansara]

I would like to give my best shot. I mean i am ready to code for this feature. Let me know.

[PaulL1]

We'd welcome any PRs on this topic.

I'd suggest by starting small to get the feel of the process. Take a look at the first time contributors guide: https://github.com/angular-ui/ng-grid/blob/master/FIRST_TIMER.md

[JLLeitschuh]

Assuming that there has been no further progress on this. Due to the silence on this post for the past month.
I have yet to actually peruse the repository thoroughly however I understand the general idea.
More related to 508 compliance for screen readers.
A few questions that should be answered before implementation:

• Should accessibility be a default functionality or something that is implemented as a feature?
• If it is implemented by default should it be toggleable so that you can disable it for your implementation?
• How should nested grids be handled. These are considered 'not assessable' and should be avoided.
• How should custom cell/rows/column headers be handled? Should they be wrapped (or are they already) so that the grid remains accessible.

[PaulL1]

1. It should be default. I see no reason that anybody would want to turn accessibility off
2. I wouldn't deal with some of the features if I were you. I'd skip expandable and leave it for someone who actually uses it. My feel is that treeView and grouping have replaced a lot of the space that expandable was filling, and that expandable has some kruft built up in it that may make things hard
3. We currently require all cells to have an enclosing <div>. I suspect you could hook on to that to add whatever accessible content you wish. But as a starting point I'd make the standard templates accessible, then if people want their custom templates to be accessible they need to implement those features themselves - as a general rule at present once you implement a custom template you accept responsibility to upgrade it to keep up with new features added to the core. It'd be nice to implement things in a way that meant that custom templates had smaller impact, but it's not critical.