-
Notifications
You must be signed in to change notification settings - Fork 943
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
Conversation
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. |
There was a problem hiding this comment.
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
@@ -296,6 +308,8 @@ const ProxyMenu: FC<ProxyMenuProps> = ({ proxyContextValue }) => { | |||
}} | |||
> | |||
<h4 | |||
autoFocus | |||
tabIndex={-1} |
There was a problem hiding this comment.
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 }} |
There was a problem hiding this comment.
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, | ||
}} | ||
/> | ||
</> |
There was a problem hiding this comment.
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
site/src/components/Abbr/Abbr.tsx
Outdated
// issues as the native title attribute as far as screen reader support | ||
expandedText: string; | ||
children: string; | ||
initialism?: boolean; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 withtoolTipText
, 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"
There was a problem hiding this comment.
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";
site/src/components/Abbr/Abbr.tsx
Outdated
// 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 |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🌠
@@ -0,0 +1,74 @@ | |||
/** |
There was a problem hiding this comment.
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?
The |
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
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 |
@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 |
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
Abbr
(abbreviation) component that builds on top of the native<abbr>
and adds some additional accessibility niceties (plus tests and stories)ProxyMenu
component to add additional text that provides context for what certain UI elements mean