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

"Create a New Repository" already an repository warning should be an error and announced #16993

Merged
merged 8 commits into from
Jul 27, 2023

Conversation

tidy-dev
Copy link
Contributor

xref: https://github.com/github/accessibility-audits/issues/4063

Description

This remediates the accessibility issue of the error of a repository already being a repo in the "Create a New Repository" not being announced and styles it as an error instead of a warning. It also make the readme overwrite warning be announced.

While testing this, I found that because the error message had a link if I tabbed through to the next input I would have to double tab because the link in the invisible aria live div. This PR also adds some basic aria live children sanitization that only looks for strings and numbers. I haven't thought of another instance of a child we would want to render, open for scrutiny. :)

Screenshots

CleanShot.2023-06-28.at.07.05.32.mp4

Release notes

Notes: [Improved] The errors and warnings in the "Create a New Repository" dialog are screen reader announced.

niik
niik previously requested changes Jul 4, 2023
@@ -69,14 +69,32 @@ export class AriaLiveContainer extends Component<
this.onTrackedInputChanged.cancel()
}

/** If the children has a tab focusable element such as a link, then we get
* hidden tabs on the screen. For screen readers, we only need the text */
private getChildrenAsText(children: React.ReactNode): string {
Copy link
Member

Choose a reason for hiding this comment

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

This stands out as not very idiomatic to me. Iterating over the (react) children is usually a good way to get into trouble as it's operating over the unprocessed JSX tree and not what would eventually get rendered.

It seems to me that what we're wanting to do here is restrict the AriaLive component to only text (which makes sense to me) then we should make it accept a required message prop of type string and stop rendering children instead of trying to poke at the child innards.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done. d2deac2 Tho, this does make the components be a lot more verbose than needed most of the time. :/ Not a huge fan of that, but, I think it does make more sense than iterating over the children (which seems discouraged).

I thought of doing a hybrid approach that says if a message is provided, use that otherwise use the children so that we only have to provide a message if the children have tab content... but that seems fraught for someone to make the mistake of having an invisible tab which is not obvious to detect. Plus.. just more code maintenance.

Copy link
Contributor Author

@tidy-dev tidy-dev Jul 6, 2023

Choose a reason for hiding this comment

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

BTW, I did regression retest along with some known edge case,

  • Autocompletion results
  • changed list status
  • filter list results
  • add repositories errors
  • tooltipped content thing
  • create repository error
  • misattributed commit warning.

@tidy-dev tidy-dev requested review from niik and sergiou87 July 6, 2023 13:23
Copy link
Member

@sergiou87 sergiou87 left a comment

Choose a reason for hiding this comment

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

Aside from a suggestion, I only found a few nits. I agree this approach is more verbose than what you had before, but I can't think of any other safe alternative 😞

Posting this in case you wanna accept my suggested changes while I test it.

Comment on lines +92 to +94
<AriaLiveContainer
message={pathScreenReaderMessage}
></AriaLiveContainer>
Copy link
Member

Choose a reason for hiding this comment

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

Nit:

Suggested change
<AriaLiveContainer
message={pathScreenReaderMessage}
></AriaLiveContainer>
<AriaLiveContainer message={pathScreenReaderMessage} />

<AriaLiveContainer
message={screenReaderMessage}
trackedUserInput={this.state.filterValue}
></AriaLiveContainer>
Copy link
Member

Choose a reason for hiding this comment

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

Nit:

Suggested change
></AriaLiveContainer>
/>

<AriaLiveContainer
message={this.props.ariaLiveMessage}
trackedUserInput={this.props.trackedUserInput}
></AriaLiveContainer>
Copy link
Member

Choose a reason for hiding this comment

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

Nit:

Suggested change
></AriaLiveContainer>
/>

>
{tooltip}
</AriaLiveContainer>
></AriaLiveContainer>
Copy link
Member

Choose a reason for hiding this comment

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

Nit:

Suggested change
></AriaLiveContainer>
/>

@@ -1,7 +1,23 @@
import { debounce } from 'lodash'
import React, { Component } from 'react'

export interface IAccessibleMessage {
Copy link
Member

Choose a reason for hiding this comment

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

Took me a while to understand that this is just some kind of auxiliar structure/interface and nothing actually used by the AriaLiveContainer.

Could we add a comment describing it and maybe even move it to its own file?

Copy link
Member

@sergiou87 sergiou87 left a comment

Choose a reason for hiding this comment

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

Tested it and works as expected! I'll approve this and let you decide about my suggestions 😄

@tidy-dev
Copy link
Contributor Author

let you decide about my suggestions

My next PR is around screen reader stuff so I will clean these suggestions up in it so I can get this out for accessibility review.

@tidy-dev tidy-dev dismissed niik’s stale review July 27, 2023 14:08

I updated the PR to match his suggestion and he is now OOO.

@tidy-dev tidy-dev merged commit 6cb23f8 into development Jul 27, 2023
7 checks passed
@tidy-dev tidy-dev deleted the create-a-repo-warning-should-be-error branch July 27, 2023 14:08
@tidy-dev tidy-dev added the accessibility Issues related to accessibility improvements label Nov 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accessibility Issues related to accessibility improvements
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants