Fix sign-in page heading hierarchy for WCAG 1.3.1 compliance#84834
Draft
Fix sign-in page heading hierarchy for WCAG 1.3.1 compliance#84834
Conversation
The sign-in page had 6 elements all rendering as h1 (via
accessibilityRole="header" with no aria-level). Per WCAG 1.3.1
there should be a single h1 per page. This adds aria-level={2}
to the footer column titles and the welcome header, keeping only
the hero text as the page's h1.
Co-authored-by: Rushat Gabhane <rushatgabhane@users.noreply.github.com>
Contributor
Author
|
The failing check is unrelated to this PR. Analysis: The failing test is Evidence: This PR only modifies two sign-in page layout files:
The failing test ( |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Explanation of Change
The sign-in page (new.expensify.com) had 6 elements all rendering as
<h1>headings becauseaccessibilityRole="header"with noaria-leveldefaults to heading level 1 in react-native-web. Per WCAG 1.3.1, there should be a single h1 per page to maintain proper heading hierarchy.This adds
aria-level={2}to the footer column titles (Features, Resources, Learn More, Get Started) inFooter.tsxand the welcome header (e.g., "Get started below.") inSignInPageContent.tsx, keeping only the hero text ("Travel and expense, at the speed of chat") as the page's h1.Fixed Issues
$ #76945
Tests
new.expensify.comin Chromedocument.querySelectorAll('[role="heading"]').forEach(el => console.log('h' + (el.getAttribute('aria-level') || '?') + ': ' + el.textContent.trim().substring(0, 60)))<h1>element)Offline tests
N/A — This is a purely semantic accessibility change that does not involve network requests.
QA Steps
HhotkeyPR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectiontoggleReportand notonIconClick)src/languages/*files and using the translation methodSTYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))npm run compress-svg)Avataris modified, I verified thatAvataris working as expected in all cases)Designlabel and/or tagged@Expensify/designso the design team can review the changes.ScrollViewcomponent to make it scrollable when more elements are added to the page.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Web: Chrome
Tested on web — hero text renders as h1, footer section titles and welcome header render as h2. No visual changes.