Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keyboard-enable all features for section 508 compliance and accessibility #2840

Open
ygyg70 opened this issue Feb 24, 2015 · 23 comments
Open

Comments

@ygyg70
Copy link

ygyg70 commented Feb 24, 2015

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

@PaulL1
Copy link
Contributor

PaulL1 commented Feb 25, 2015

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

@PaulL1 PaulL1 added this to the Future milestone Feb 25, 2015
@ygyg70
Copy link
Author

ygyg70 commented Feb 25, 2015

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
Copy link
Contributor

PaulL1 commented Feb 26, 2015

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
Copy link
Author

ygyg70 commented Feb 26, 2015

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

@c0bra
Copy link
Contributor

c0bra commented Mar 2, 2015

@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.

@PaulL1 PaulL1 changed the title Keyboard-enable all features for section 508 compiance Keyboard-enable all features for section 508 compliance and accessibility Mar 17, 2015
@rajulkansara
Copy link

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

@PaulL1 PaulL1 mentioned this issue Apr 22, 2015
@PaulL1
Copy link
Contributor

PaulL1 commented Apr 22, 2015

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
Copy link
Contributor

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
Copy link
Contributor

PaulL1 commented May 27, 2015

  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.

@JLLeitschuh
Copy link
Contributor

Many of these features have been added to the core and some of the more relevant features.

Related: #3893

@hohwille
Copy link

hohwille commented Oct 7, 2015

If you want to see a working example with proper aria setup you can get some inspiration here:
http://examples.sencha.com/extjs/6.0.0/examples/classic/aria/

ui-grid is using default focus mode what breaks the keyboard control in combination with screenreaders.
http://tink.uk/understanding-screen-reader-interaction-modes/

@gethinoakes
Copy link

Does anybody have a workaround for getting aria labels to work on grid cells?
The aria labels are implemented already on the selection column and appears correctly in a screen reader but the screen reader doesn't pick up on aria labels/roles on a normal grid cell if I add it in.

@shafqatalix
Copy link

Is there any way to change the rendering from div to table for grid, to make it 508 compliant?

@hohwille
Copy link

hohwille commented Dec 7, 2015

Div is not forbidden by 508:
http://www.ecfr.gov/cgi-bin/text-idx?SID=aed1a91a2d4f562c58049c82d84ed21d&mc=true&node=pt36.3.1194&rgn=div5#se36.3.1194_122

You need proper markup that can also be div with according WAI-ARIA attribution. IMHO the main issue is how focus modes are handled what seems to break keyboard control when screen-reader gets active.

@rangarajl
Copy link

is ui-grid latest version 508 compliant now?

@JLLeitschuh
Copy link
Contributor

I worked really hard on this for a summer as an intern. The answer is, somewhat.
There are some features that have accessibility support and others that do not.
I'm no longer contributing to ui-grid any longer.

You can see what support exists here:
http://ui-grid.info/docs/#/tutorial/122_accessibility

@daKuleMune
Copy link

The company I work for needs this feature, and I have been allowed to do pull requests for my contributions back into the community. I will flesh out full 508 compliance for I.E. 11. If anyone else is also working on this which it dons't sound like there is, let's coordinate if possible.

@JLLeitschuh
Copy link
Contributor

I worked on this for Kronos when I was an intern there. The current A11Y implementation that exists I think is almost completely my work.

Some words of warning to get you on the right path.
The drop down menus are actually below the grid on the DOM but are moved with CSS to make them look like they are in the right spot.

There is no good way to represent the size of the grid when using infinite scroll because the entire grid isn't there to get a count of the cells.

All of the testing that I did was with chrome with the MacOSX developer tools. I consistently experienced different behaviour between chrome, firefox, and safari.
I was able to get chrome to behave the best consistently so I tuned things to it.
I opened two bugs with apple about safari not behaving correctly.

I don't know if anyone will be able to view these as I posted them with my account but I'll link to them here:
https://bugreport.apple.com/web/?problemID=21604679
https://bugreport.apple.com/web/?problemID=21223201

I hope that this gets you started down the right path.
I don't check UI-Grid issues very often any longer as I'm no longer working on anything that uses it.
Best of luck.

@daKuleMune
Copy link

Sadly I ended up getting the red light on my ability to contribute my fixes back into the community, such is the drag of office politics. But thanks for the details.

@JLLeitschuh
Copy link
Contributor

That stinks. I usually ask if I can contribute fixes back to open source projects up front during the interview and probably wouldn't work somewhere where I couldn't. Good luck.

@stale
Copy link

stale bot commented May 23, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label May 23, 2018
@stale
Copy link

stale bot commented Jun 22, 2018

This issue has been automatically closed because it has not had recent activity. If you believe that this is still an issue in the latest version, feel free to re-open it. Thank you for your contributions.

@stale stale bot closed this as completed Jun 22, 2018
@mportuga mportuga reopened this Jun 23, 2018
@stale stale bot removed the stale label Jun 23, 2018
@mportuga
Copy link
Member

Note need to add help wanted to this issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests