Docs: Navbar logo has extra decorative "TypeScript ESLint logo" narration

[JoshuaKGoldberg]

Before You File a Documentation Request Please Confirm You Have Done The Following...

• I have looked for existing open or closed documentation requests that match my proposal.
• I have read the FAQ and my problem is not listed.

Suggested Changes

The structure of the TypeScript ESLint logo & title in the navbar is roughly:

<a href="...">
  <img alt="TypeScript ESLint logo" src="..." />
  TypeScript ESLint
</a>

As a result, screenreaders narrate it as roughly like:

TypeScript ESLint logo TypeScript ESLint

Discussed on stream with @BenDMyers on Twitch: https://www.twitch.tv/videos/1498962341. The logo doesn't add any semantic meaning to the page. We should consider it decorative. See https://www.w3.org/WAI/tutorials/images/decorative for more details.

Affected URL(s)

[Josh-Cena]

logo.alt is included in the default template. In hindsight, I don't even know if it makes sense to provide an alt for any logo that has an accompanying text title (or even those without, considering logos are decorative)...

[armano2]

alt should be present on logo and we should include aria-hidden to

[Josh-Cena]

For example, if the logo image is broken, I don't think we should show an alt text—should we? An empty alt seems good enough.

[JoshuaKGoldberg]

Yeah if the image is decorative there's no need to include an alt.

[BenDMyers]

W3C's Web Accessibility Initiative has guidance on alt text for functional images, which specifically calls out logos used within links.

Their first example is an image used alone as a linked logo. Here, they recommend supplying alt text, since the image's alt text will be used to populate the link's accessible name for assistive tech.

Their second example is what we have on the TypeScript ESLint site: a logo image within the link text.

The image does not represent different functionality or convey other information than that already provided in the link text, so a null (empty) value is applied, (alt=""), to avoid redundancy and repetition. In effect the image is a decorative adjunct or visual cue to the link text…

[BenDMyers]

Tried to fix this, but found that even if we supply an empty alt config on our end, Docusaurus populates it with the site title anyway. Filed a bug on Docusaurus at facebook/docusaurus#7658, and I'll spin up a PR to address it on their end as well.

[BenDMyers]

The PR to address this in Docusaurus (facebook/docusaurus#7659) has been merged in. We just need to wait for the team to cut a new beta release before we can fix this here.

[Josh-Cena]

Spoiler: next release will not be beta 😄

[JoshuaKGoldberg]

[BenDMyers]

Following up on this — the Docusaurus team has cut a v2.0.0-rc.1 release candidate that includes facebook/docusaurus#7659, which is the upstream fix for this issue. If we upgraded to that release candidate, we'd get the fix. However, since it is a release candidate, Docusaurus v2.0 seems imminent, and so it could probably just be simpler to wait for 2.0 proper.

@JoshuaKGoldberg Thoughts?

[JoshuaKGoldberg]

Yeah this bug isn't hard blocking anybody and there's a separate PR already for 2.0. Thanks for the update!

[BenDMyers]

Cool - since there's a PR up for it anyways, would you be willing to mark this as to be resolved by #5377?

Wait, never mind. We'll still need to actually update the alt's config after rc.1 is in.

[Josh-Cena]

Hey FYI 2.0 is hopefully scheduled tomorrow, after which I'll update that PR accordingly