USWDS-Site: Added file input accessibility test page

[RachelCorsino]

Summary

Added accessibility test page for file input component

Important

We need to update the changelog dates before merge

Related issue

Closes #2877

Preview link

File Input Component Page
File Input Accessibility Tests Page

Testing and review

Follow these steps:

1. Confirm that both the main component page and the accessibility tests page have the correct compliance tag at the top.
2. Confirm that the main component page links to the accessibility tests page in the side navigation.
3. Confirm that the main component page links to the accessibility tests page from the accessibility guidance section.
4. Confirm that the main component page shows the accessibility tests summary.
5. Check that accessibility tests page provides the correct counts for each test status type.
6. Confirm the test checklist summaries and data are accurate.
7. Confirm no visual issues.
8. Confirm there is an appropriate changelog entry on both the main component page and the accessibility tests page.

[amyleadem]

Thanks for working this @RachelCorsino. Added some comments below and tagged who I thought would be the best to respond to each item. Let me know if you have questions!

[amycole501]

Wondering if we have an extra "and" on the verbiage for test 1.4.1

Otherwise looks good!

[amyleadem]

After discussing this with @amycole501 and @alex-hull, we decided to move forward with the following plan:

• Update the 3.3.1 status to pass and update the summary. The criterion is actually scoped to only require a detailed error message in visual text form on the page. 3.3.1 does not require it to be read out via screen reader. Instead, the screen reader portion of that is captured in 1.3.1 (details in the next bullet point)
• Update the 1.3.1 status to pass with exceptions and update the summary to include a note about error messages. @amycole501 helpfully summarized to criteria to mean "what you see on the page is what you hear".
• Remove the 4.1.3 checklist item from the page at this time. It is a WCAG 2.2 requirement that we will incorporate in future re-tests of the component.

@amycole501 and @alex-hull, let me know if I missed anything here.

[RachelCorsino]

Wondering if we have an extra "and" on the verbiage for test 1.4.1

Otherwise looks good!

@amycole501 I agree it sounds weird and seems like there's an extra "and". How is this supposed to read?

1. When you view the file input component, focus indicators, text labels, field descriptions and messaging all help establish meaning.
   or (this probably doesn't follow the way we word things but...)
2. Focus indicators, text labels, and field descriptions and messaging all help establish meaning when you view the file input component.

[amycole501]

Wondering if we have an extra "and" on the verbiage for test 1.4.1
Otherwise looks good!

@amycole501 I agree it sounds weird and seems like there's an extra "and". How is this supposed to read?

1. When you view the file input component, focus indicators, text labels, field descriptions and messaging all help establish meaning.
   or (this probably doesn't follow the way we word things but...)
2. Focus indicators, text labels, and field descriptions and messaging all help establish meaning when you view the file input component.

@RachelCorsino I like the first sentence better for 1.4.1

[finekatie]

Resolved convo about suggested change that we're not doing at this time. Looks good to me otherwise!

[amyleadem]

Added some additional suggestions for review. We can discuss these in our call in a few minutes.

[amyleadem]

LGTM. Thanks team for all the discussion on this!

[finekatie]

Looks good.