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

[Accessibility] Spaces List Edit and Delete Buttons need more context #27744

Closed
aphelionz opened this issue Dec 23, 2018 · 1 comment
Closed
Assignees
Labels
Feature:Security/Spaces Platform Security - Spaces feature Project:Accessibility Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! WCAG A

Comments

@aphelionz
Copy link
Contributor

Steps to reproduce (assumes ChromeVox or similar)

  1. Open /app/kibana#/management/spaces/list
  2. Tab to the "edit" and "delete buttons on any row

screenshot_20181223_113855

Actual Result, Respectively

"Edit"
"Delete"

Expected Result

"Edit [insert human-readable name of current space]"
"Delete [insert human-readable name of current space]"

Kibana Version:
Relevant WCAG Criteria: 3.3.2 Labels or Instructions https://www.w3.org/WAI/WCAG21/quickref/#labels-or-instructions
Meta Issue: #25512

@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-security

@kobelb kobelb added the Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! label Jan 2, 2019
@legrego legrego self-assigned this Jan 2, 2019
legrego added a commit to legrego/kibana that referenced this issue Jan 3, 2019
## Summary
Fixes elastic#27744

cc @elastic/eui-design -- It appears that the [`DefaultItemAction`](https://elastic.github.io/eui/#/display/tables) can only accept hard-coded `name`/`description` values. While this isn't necessarily a bad thing, I'm wondering if the linked issue (elastic#27744) will be a common enough occurrence within Kibana to make the DefaultItemAction less useful. What do you think about allowing functions for the `name` and `description` fields, so that they can get access to the row's record, and provide context as necessary?
legrego added a commit to legrego/kibana that referenced this issue Jan 3, 2019
## Summary
Fixes elastic#27744

cc @elastic/eui-design -- It appears that the [`DefaultItemAction`](https://elastic.github.io/eui/#/display/tables) can only accept hard-coded `name`/`description` values. While this isn't necessarily a bad thing, I'm wondering if the linked issue (elastic#27744) will be a common enough occurrence within Kibana to make the DefaultItemAction less useful. What do you think about allowing functions for the `name` and `description` fields, so that they can get access to the row's record, and provide context as necessary?
legrego added a commit that referenced this issue Jan 3, 2019
## Summary
Fixes #27744

cc @elastic/eui-design -- It appears that the [`DefaultItemAction`](https://elastic.github.io/eui/#/display/tables) can only accept hard-coded `name`/`description` values. While this isn't necessarily a bad thing, I'm wondering if the linked issue (#27744) will be a common enough occurrence within Kibana to make the DefaultItemAction less useful. What do you think about allowing functions for the `name` and `description` fields, so that they can get access to the row's record, and provide context as necessary?
legrego added a commit to legrego/kibana that referenced this issue Jan 3, 2019
Fixes elastic#27744

cc @elastic/eui-design -- It appears that the [`DefaultItemAction`](https://elastic.github.io/eui/#/display/tables) can only accept hard-coded `name`/`description` values. While this isn't necessarily a bad thing, I'm wondering if the linked issue (elastic#27744) will be a common enough occurrence within Kibana to make the DefaultItemAction less useful. What do you think about allowing functions for the `name` and `description` fields, so that they can get access to the row's record, and provide context as necessary?
legrego added a commit that referenced this issue Jan 3, 2019
## Summary
Fixes #27744

cc @elastic/eui-design -- It appears that the [`DefaultItemAction`](https://elastic.github.io/eui/#/display/tables) can only accept hard-coded `name`/`description` values. While this isn't necessarily a bad thing, I'm wondering if the linked issue (#27744) will be a common enough occurrence within Kibana to make the DefaultItemAction less useful. What do you think about allowing functions for the `name` and `description` fields, so that they can get access to the row's record, and provide context as necessary?
legrego added a commit that referenced this issue Jan 4, 2019
Fixes #27744

cc @elastic/eui-design -- It appears that the [`DefaultItemAction`](https://elastic.github.io/eui/#/display/tables) can only accept hard-coded `name`/`description` values. While this isn't necessarily a bad thing, I'm wondering if the linked issue (#27744) will be a common enough occurrence within Kibana to make the DefaultItemAction less useful. What do you think about allowing functions for the `name` and `description` fields, so that they can get access to the row's record, and provide context as necessary?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Security/Spaces Platform Security - Spaces feature Project:Accessibility Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! WCAG A
Projects
None yet
Development

No branches or pull requests

5 participants