LG-7817 Ensure that screen reader follows search page hierarchy#7459
LG-7817 Ensure that screen reader follows search page hierarchy#7459eileen-nava wants to merge 8 commits intomainfrom
Conversation
| <PageHeading>{t('in_person_proofing.headings.location')}</PageHeading> | ||
| {arcgisSearchEnabled && ( | ||
| <AddressSearch onAddressFound={handleFoundAddress} registerField={registerField} /> | ||
| )} | ||
| <p>{t('in_person_proofing.body.location.location_step_about')}</p> | ||
| {locationsContent} | ||
| <BackButton onClick={toPreviousStep} /> | ||
| <div aria-live="polite"> | ||
| {arcgisSearchEnabled && ( | ||
| <AddressSearch onAddressFound={handleFoundAddress} registerField={registerField} /> | ||
| )} | ||
| </div> | ||
| <div role="status"> | ||
| <p>{t('in_person_proofing.body.location.location_step_about')}</p> | ||
| {locationsContent} | ||
| <BackButton onClick={toPreviousStep} /> | ||
| </div> | ||
| </> |
There was a problem hiding this comment.
Note that we should be using the in-person-location-post-office-search component for address-search related work.
Actually, the address-search conditional should be removed since this was merged...
# Conflicts: # app/javascript/packages/document-capture/components/in-person-location-step.tsx
|
Need to know whether the back button bug is a problem introduced by this change... |
dd5ec56 to
98fdf24
Compare
...vascript/packages/document-capture/components/in-person-location-post-office-search-step.tsx
Show resolved
Hide resolved
| <PageHeading>{t('in_person_proofing.headings.location')}</PageHeading> | ||
| {arcgisSearchEnabled && ( | ||
| <div aria-live="polite"> | ||
| <AddressSearch onAddressFound={handleFoundAddress} registerField={registerField} /> |
There was a problem hiding this comment.
this is really a thought for design - but wondering if the search field should clear the user's input after clicking the search button. And if the "no matches found" text has enough prominence on the page. Right a user see's the address they input 2x on the page and it's hard to notice the "no match" text.
There was a problem hiding this comment.
oh wait, is the 2nd address shown on the page the one that was actually used by the search function?/ the closest match to the input? that's unclear. I'll add these thoughts in slack so design can comment.
There was a problem hiding this comment.
crossing out the portions that are likely not applicable since the 2nd address is for debugging
| <div role="status"> | ||
| <p>{t('in_person_proofing.body.location.location_step_about')}</p> | ||
| {locationsContent} | ||
| <BackButton onClick={toPreviousStep} /> |
There was a problem hiding this comment.
another thing happening with the screen reader...it's currently reading the text that appears alongside the search button after it reads out "back"
There was a problem hiding this comment.
if that address is removed then this screen reader issue should be ignored.
There was a problem hiding this comment.
i've been trying to test this page but voiceover +chrome are acting up (constantly freezing and not auto reading the page) So I'm not 100% sure if it's just a chrome issue or if removing the "<" would fix the double reading of back (since the 2 pieces of text are separate).
| const button = ( | ||
| <Button isUnstyled {...props}> | ||
| ‹ {t('forms.buttons.back')} | ||
| <span aria-hidden="true">‹ </span> |
There was a problem hiding this comment.
As I said in slack, the screenreader read "back" twice because it read "back" for both the arrow "<" and the word "back"
I fixed this glitch by adding aria-hidden="true" to the arrow "<". Documentation notes that aria-hidden is a way to fix duplicated content.
|
I am closing this PR. The non-draft PR, which is ready for review, is #7487. |
This is a draft PR to share my work. This PR is not ready for review.
Currently, the screen reader correctly reads results and follows the hierarchy of the page. However, there's a bug where the screenreader will read "Back" twice. I included a video of the buggy behavior.
BackReadsTwice.mov