Thanks to visit codestin.com
Credit goes to github.com

Skip to content

fix: make ProxyMenu more accessible to screen readers #11312

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

Merged
merged 18 commits into from
Jan 7, 2024

Conversation

Parkreiner
Copy link
Member

@Parkreiner Parkreiner commented Dec 21, 2023

No issue to link – just trying to do some random fixes/improvements since it's the last day before Christmas break. Definitely not expecting anyone to tackle this until after we all get back.

Changes made

  • Adds a general-purpose Abbr (abbreviation) component that builds on top of the native <abbr> and adds some additional accessibility niceties (plus tests and stories)
  • Updates the ProxyMenu component to add additional text that provides context for what certain UI elements mean

return false;
// - The latency reported is older than the refetch date. This means the
// latency is stale and we should show a loading spinner until the new
// latency is fetched.
Copy link
Member Author

Choose a reason for hiding this comment

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

Only change here is that I reformatted the comment to properly fit in an 80px column

@Parkreiner Parkreiner requested review from a team and Kira-Pilot and removed request for a team December 21, 2023 20:03
@Parkreiner Parkreiner marked this pull request as ready for review December 21, 2023 20:04
@@ -296,6 +308,8 @@ const ProxyMenu: FC<ProxyMenuProps> = ({ proxyContextValue }) => {
}}
>
<h4
autoFocus
tabIndex={-1}
Copy link
Member Author

@Parkreiner Parkreiner Dec 21, 2023

Choose a reason for hiding this comment

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

Safety nets to make extra sure that the header receives focus when the menu opens. 90% sure tabIndex shouldn't be necessary, but it's just a precaution to make sure that it's never directly tab-able as an interactive element

@@ -329,6 +349,9 @@ const ProxyMenu: FC<ProxyMenuProps> = ({ proxyContextValue }) => {
})
.map((proxy) => (
<MenuItem
key={proxy.id}
selected={proxy.id === selectedProxy?.id}
css={{ fontSize: 14 }}
Copy link
Member Author

Choose a reason for hiding this comment

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

Just moving the single-line props to the top to help with readability

color,
}}
/>
</>
Copy link
Member Author

@Parkreiner Parkreiner Dec 21, 2023

Choose a reason for hiding this comment

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

Annoyingly, Tooltip doesn't accept children arrays, so the Fragment is necessary

// issues as the native title attribute as far as screen reader support
expandedText: string;
children: string;
initialism?: boolean;
Copy link
Member

@Kira-Pilot Kira-Pilot Jan 2, 2024

Choose a reason for hiding this comment

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

NIT: what do you think about the var names "tooltipText" (instead of "expandedText") and "hasAcronym" (instead of "initialism")? Expanded makes me think there is a dropdown or accordion and I had to google initialism.

Copy link
Member Author

Choose a reason for hiding this comment

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

So, I think I've done a bad job of adding enough context:

  • I can see if there are some better alternatives for expandedText, but with toolTipText, it feels like it's putting much more emphasis on one type of user (sighted users who can see the tooltip), vs accommodating both them and screen-reader users. If a user's been blind all their life, they'll have no idea what a tooltip even is. Even in the WCAG spec, they call this "the expanded form of abbreviations"
  • The initialism prop is there to make sure that initialisms are pronounced like initialisms instead of just general acronyms/abbreviations. Like, NASA is an acronym, but you wouldn't want to pronounce it like an initialism, because then it'd be read "N-A-S-A"

Copy link
Member

Choose a reason for hiding this comment

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

Ah, thanks for those distinctions; makes sense. I like the proposal you came up with, i.e.
pronunciation?: "shorthand" | "acronym" | "initialism";

// There isn't a dedicated HTMLAbbrElement type; have to go with base type
type AbbrProps = Exclude<HTMLAttributes<HTMLElement>, "title" | "children"> & {
// Not calling this "title" to make it clear that it doesn't have the same
// issues as the native title attribute as far as screen reader support
Copy link
Member

Choose a reason for hiding this comment

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

I don't know that this rename lends a lot of clarity, tbh - I might just use "title" so there's less cognitive overhead

Copy link
Member Author

@Parkreiner Parkreiner Jan 3, 2024

Choose a reason for hiding this comment

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

Yeah, I can see that. As I've been doing research, it seems that title is usually next to useless for screen readers, but reframing it like "the API is 99% the same as the native <abbr>, and we fixed the title prop" would make things more clear for other folks

@@ -0,0 +1,89 @@
import { render, screen } from "@testing-library/react";
import { Abbr } from "./Abbr";
Copy link
Member

Choose a reason for hiding this comment

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

🌠

@@ -0,0 +1,74 @@
/**
Copy link
Member

Choose a reason for hiding this comment

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

There are a lot of comments in here for a relatively small component. Are there any we can shorten?

@Kira-Pilot
Copy link
Member

The initializeText fn was a nice touch. It would be good to be on the same page as a team so we can strike the right balance between being accessible and acknowledging the technical expertise of our users. I can see us using this component for an acronym like DERP, but perhaps we shouldn't use it for URL? What are your thoughts?

@Parkreiner
Copy link
Member Author

Parkreiner commented Jan 3, 2024

I can see us using this component for an acronym like DERP, but perhaps we shouldn't use it for URL? What are your thoughts?

I think it's kind of up to discretion, but adding it everywhere shouldn't hurt. I think "URL" is established enough that screen readers should pronounce it correctly, but if it ever gets pronounced like "Earl" for whatever reason, this component should be able to help fix that. Then again, that CLI/"klee" example I mentioned in the comments was actually something I ran into for this PR, so it's not really possible to know until it's tested

It would be good to be on the same page as a team so we can strike the right balance between being accessible and acknowledging the technical expertise of our users

Yeah, if Coder were a less specialized, more mass-market product, I'd probably say "slap the component everywhere", just because even if an acronym is obvious to native speakers, it would help people like English-as-a-Second-Language learners. But I feel like even if someone doesn't speak English natively, if they work in software, they probably know these acronyms

@Parkreiner
Copy link
Member Author

@Kira-Pilot Ended up taking all the feedback into account, and now I'm realizing that there is a case I didn't properly account for.

It's going to require a bit more manual testing with a screen reader, though, and since this is kind of a "pet project PR", I'm going to put this away until near the end of the week

@Parkreiner Parkreiner merged commit 31f8fac into main Jan 7, 2024
@Parkreiner Parkreiner deleted the mes/a11y-proxy-menu branch January 7, 2024 23:37
@github-actions github-actions bot locked and limited conversation to collaborators Jan 7, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants