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

Kashkovsky intl a11y, attempt 2 #4161

Closed
wants to merge 9 commits into from

Conversation

radegran
Copy link

@radegran radegran commented Aug 13, 2020

Fixed conflicts and added test for PR #3550 that has come to a halt.

@changeset-bot
Copy link

changeset-bot bot commented Aug 13, 2020

💥 No Changeset

Latest commit: 24d1e60

Merging this PR will not cause any packages to be released. If these changes should not cause updates to packages in this repo, this is fine 🙂

If these changes should be published to npm, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@codesandbox-ci
Copy link

codesandbox-ci bot commented Aug 13, 2020

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 24d1e60:

Sandbox Source
react-codesandboxer-example Configuration

@radegran radegran mentioned this pull request Aug 14, 2020
@bladey bladey added pr/bug-fix PRs that are specifically addressing a bug pr/needs-review PRs that need to be reviewed to determine outcome labels Aug 24, 2020
@@ -73,8 +75,41 @@ type FormatOptionLabelMeta = {
inputValue: string,
selectValue: ValueType,
};
export type AccessibilityProp = {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about moving these to a separate file?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you are right! I'll try to find a good place for them.

@@ -1815,10 +1868,14 @@ export default class Select extends Component<Props, State> {
renderLiveRegion() {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be good to abstract this to a separate component at this time. What do you think?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your feedback!
I am not sure. Looking at other render helpers, renderLiveRegion seems to line up pretty well? On the other hand one could argue for a decoupling exercise of the whole Select class, being ~1600 lines tall. But perhaps that work should be logged in a separate work package. What are you thoughts?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree! You are following the convent. Also agree that this is 1600 lines. So maybe another PR would be good to refactor some of the render* function into separate components.

Copy link

@TheHollidayInn TheHollidayInn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Annotation 2020-09-08 164937

Testing manually seems to work!! Good job :D

TheHollidayInn added a commit to KoalaTeaCode/react-select that referenced this pull request Sep 9, 2020
@TheHollidayInn TheHollidayInn mentioned this pull request Sep 9, 2020
@horrigan
Copy link

Hi guys, the example looks great! Btw Is anyone working on merging this PR? Do you guys need any help? It seems @TheHollidayInn has done all the job.

Copy link
Collaborator

@ebonow ebonow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TheHollidayInn @radegran Would you mind taking a look at the comments regarding the propName? accessibility as a prop name simply would not be descriptive enough. Recommendation would be ariaLiveConfig or something of a similar nature.

@@ -75,6 +79,8 @@ type FormatOptionLabelMeta = {
};

export type Props = {
/* Custom ARIA message functions */
accessibility?: AccessibilityProp,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this is a bit of semantics, but I believe accessibility is a bit vague for a prop.

Would you be willing to consider something more along the lines of ariaLiveConfig? I think it better encapsulates the functionality.

Additionally, this would provide more clarity and avoids confusion with perhaps other things aria/accessibility related.

@ebonow
Copy link
Collaborator

ebonow commented Dec 15, 2020

Overview

This proposed PR adds the ability for users to configure the ariaLive messaging configuration to allow custom messages.

Problem

This addresses two gaps:

  1. The hardcoded aria live message templates are written in English and therefore do not support localization.
  2. The templates are not configurable and therefore custom user messages are not possible especially when additional data can be presented in a custom Option component such as when formatOptionLabel returns a JSX component instead of a string

Solution

The internal instructionsAriaMessage class should be exposed so that a developer can override any of the default aria-live event messages.

Related Issues solved by this

#3352 Aria messages cannot be localized
#3685 aria-live region gives incorrect instructions in one use case
#3691 Customize messages for accessibility
#4001 Screen reader support for only English text
#4134 (comment) Pass something besided string to getOptionLabel()?

@ebonow
Copy link
Collaborator

ebonow commented Dec 15, 2020

@kylemh regarding your comments from here, perhaps you were mistaking this with another PR because of the accessibility prop which would likely be better named as something like ariaLiveConfig based on the scope of the changes.

I also agree that having an "accessibility catch-all prop" that includes all things aria would not be a good idea.

@kylemh
Copy link

kylemh commented Dec 15, 2020

💯 thank you for helping me read correctly

The name change would help for sure.

@ebonow ebonow added this to the 3.2 milestone Dec 15, 2020
@Methuselah96 Methuselah96 added pr/enhancement PRs that are specifically enhancing the project and removed pr/bug-fix PRs that are specifically addressing a bug labels Dec 18, 2020
@ebonow
Copy link
Collaborator

ebonow commented Dec 22, 2020

Note to future self, pull this PR with documentation PR and rename prop name

@ebonow ebonow self-assigned this Dec 22, 2020
@JedWatson JedWatson modified the milestones: 3.2, 3.3 Jan 13, 2021
@ebonow
Copy link
Collaborator

ebonow commented Jan 21, 2021

Please note that there has been no response to requests for updates. I have began creating a new PR inspired by this and hope to address several other gaps in the aria live messaging. I will close this once I have a submission ready.

@ebonow ebonow mentioned this pull request Jan 21, 2021
@ebonow
Copy link
Collaborator

ebonow commented Jan 21, 2021

Greetings @radegran ,

Thank you for your efforts resurrecting this PR. Your efforts are much appreciated. There were some issues with merging and code review suggestions that were not addressed so I have taken these efforts as a starting point to create #4390 . I will be closing this issue so we can continue on with attempt 3.

@ebonow ebonow closed this Jan 21, 2021
@radegran
Copy link
Author

Greetings @radegran ,

Thank you for your efforts resurrecting this PR. Your efforts are much appreciated. There were some issues with merging and code review suggestions that were not addressed so I have taken these efforts as a starting point to create #4390 . I will be closing this issue so we can continue on with attempt 3.

@ebonow, I have not been keeping track of this PR for some time. Glad to see you moving forward with it, best of luck!

@ebonow ebonow removed this from the 4.1 milestone Jan 22, 2021
@ebonow ebonow mentioned this pull request Feb 1, 2021
14 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pr/enhancement PRs that are specifically enhancing the project pr/needs-review PRs that need to be reviewed to determine outcome
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants