Page MenuHomePhabricator

[web] Link wordmark in header to app "homepage"
ClosedPublic

Authored by abosh on Apr 1 2022, 5:10 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Aug 29, 10:36 PM
Unknown Object (File)
Thu, Aug 29, 10:36 PM
Unknown Object (File)
Thu, Aug 29, 10:36 PM
Unknown Object (File)
Thu, Aug 29, 10:36 PM
Unknown Object (File)
Thu, Aug 29, 10:36 PM
Unknown Object (File)
Thu, Aug 29, 10:36 PM
Unknown Object (File)
Thu, Aug 29, 10:35 PM
Unknown Object (File)
Thu, Aug 29, 10:34 PM

Details

Summary

Addressed issue where the "Comm" wordmark in header did not link to the app "homepage". Now, when a user hovers over the "Comm" wordmark on a page "Comm Home" appears and clicking on the wordmark will link to the app root/homepage.

Video:

More context on Linear.

Test Plan

Ensured that the Comm wordmark on different pages on the web app linked back to the root page with all the chats. Tested on Chrome/Safari.

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

abosh edited the summary of this revision. (Show Details)
web/style.css
84–86 ↗(On Diff #10974)

This CSS is to ensure that the wordmark's color remained the same even after becoming a link to the app's homepage (anchor tags are blue by default).

ashoat requested changes to this revision.Apr 1 2022, 7:31 PM

How hard would it be to avoid actually refreshing the page? We have some quirky custom routing unfortunately, but I think something like this would work:

this.props.dispatch({
  type: updateNavInfoActionType,
  payload: { tab: 'Chat' },
});

The downside is that the fact that the default is 'Chat' will now be stored in two places (there and url-utils.js). We could try using history.push('/') instead, but I don't think we currently use that anywhere. Not entirely sure it would work. We could also just avoid copy-pasting Chat by defining some constant defaultTab somewhere.

This revision now requires changes to proceed.Apr 1 2022, 7:31 PM

Clicking on the wordmark takes the user to the main Chat tab without refreshing the page. The <a> tag has been removed and instead the <h1> tag uses an onClick event handler to update the navigation info.

atul requested changes to this revision.Apr 6 2022, 11:39 AM
atul added inline comments.
web/style.css
84–86 ↗(On Diff #11117)

I think it would be clearer to style the wordmark directly

eg

<h1 className={css.wordmark}>Comm</h1>
h1.wordmark {
  cursor: pointer;
}

Even outside of that, it looks like you're introducing a new div.main-header > h1 selector right below another one that already exists?

This revision now requires changes to proceed.Apr 6 2022, 11:39 AM

Moved CSS into already existing div.main-header > h1 selector. Will defer to your guys' input on adding the .wordmark class because there was already a CSS selector/CSS styles that were in the h1 selector, although I think it's clearer if we rename the selector to use a class instead of h1.

ashoat added a reviewer: benschac.

Looks good to me, but curious for @benschac's perspective on styling an h1 directly as a link versus wrapping it in an a. My suspicion is that it's less semantic and thus might be worse for accessibility, but I'm not actually sure

https://stackoverflow.com/questions/20174426/html-how-to-make-h1-h2-etc-as-links -- this looks right.

https://www.w3.org/TR/WCAG20-TECHS/H80 -- I think a an <a> tag in an <h1> tag makes sense.

On a side note if we're going to be serious about accessibility, we should probably use aria labels https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA and running the site through: https://www.webaccessibility.com

This revision now requires changes to proceed.Apr 7 2022, 7:59 AM

Updated h1 tag by wrapping Comm text in an anchor, per @benschac's suggestion. Also allows for a title attribute on the a when hovering, which increases accessibility.

With regards to ARIA labels, according to the top answer of this StackOverflow question, only the title attribute should be used (not both title and aria-label.) However, in the replies to the top answer, someone notes that the title attribute is not read by screenreaders by default, so aria-label should be used instead.

I tested this by installing this screenreader Chrome extension.

When using only the title attribute (which says "Comm Home"): the screenreader says Comm. Link heading 1 header. So it's just reading the text inside the anchor tag.

When using both the title and an aria-label attribute that says "Go to Comm Home": the screenreader says Go to Comm Home. Link heading 1 header.

I prefer both title and aria-label (title for visual, aria-label for screenreader), but people on the internet seem split on including one or the other or both. Some argue that ARIA labels should only be used for things that aren't visually apparent like alt text on an image, but in my opinion, if a screenreader can't pick up on something (like a title element in an anchor tag), I think we should use ARIA labels in conjunction with title elements.

web/style.css
84 ↗(On Diff #11182)

I don't think you need this level of specificity.

.wordmark > a should be enough. I could be wrong

ashoat requested changes to this revision.Apr 8 2022, 8:07 AM

Thanks for sharing all that research, @yayabosh! I think I agree with you that including both title and aria-label is a good idea

This revision now requires changes to proceed.Apr 8 2022, 8:07 AM

Removed div.main-header CSS from selector on <a> tag. Also added aria-label: Go to Comm Home to wordmark. Screenreader now reads "Go to Comm Home" when clicking on wordmark.

This revision is now accepted and ready to land.Apr 11 2022, 8:36 AM