Closed christinec-fftc closed 1 year ago
cc @RakshindaAslam
Moved to icebox - to be handed over to the new 686 team.
There is also this documentation https://design.va.gov/about/developers/using-web-components#how-to-migrate-to-web-components
@christinec-fftc looking at the acceptance criteria:
Are those checkes automated already? If there is automated checks for these items, can you link us to some examples so we can understand how they are performed?
or do we need to manually verify these items?
There is definitely automation for a11y checks, but they may not be 100% foolproof so manual testing is still needed. The front end orientation has a great overview of these checks. There was a recent slack thread about making these sessions available asynchronously, but I haven't been able to access it yet. I'm happy to share what I've learned, but would still recommend going to the orientation. I will be going again myself. Feel free to setup some time if we want to walk through these checks together since the next session may be weeks out. There's also a little info on these checks here.
For zoom checks, product must be usable at 200%, 300% and 400% zoom. And for the screenreader check, we were told manually testing with 1 screenreader is sufficient.
PR has been merged into main
Issue Description
Migrate the following uses of the Telephone component to use the new web components version GetFormHelp.jsx VeteranInformationComponent.js helpers.js
Front end tasks
Acceptance Criteria
Appendix
Ensure your code changes are covered by E2E tests (expand)
- Add E2E tests if none exist for this addition/change. - Update existing E2E tests if this code will change functionality. - Include axe checks, including hidden contentRun axe checks using the Chrome or Firefox browser plugin (expand)
- Ensure no heading levels are skipped. - Ensure all buttons and labeled inputs use semantic HTML elements. - Ensure all buttons, labeled elements and images are identified using HTML semantic markers or ARIA roles. - Ensure form fields have clearly defined boundaries or outlines. - Ensure form fields do not use placeholder text. - Ensure form fields have highly visible and specific error states.Test for color contrast and color blindness issues (expand)
- All text has appropriate contrast.Zoom layouts to 400% at 1280px width (expand)
- Ensure readability and usability are supported when zoomed up to 400% at 1280px browser width - Ensure no content gets focused offscreen or is hidden from view.Test with 1 or 2 screen readers (expand)
- Ensure the page includes a skip navigation link. - Ensure all links are properly descriptive. - Ensure screen reader users can hear the text equivalent for each image conveying information. - Ensure screen reader users can hear the text equivalent for each image button. - Ensure screen reader users can hear labels and instructions for inputs. - Ensure purely decorative images are not announced by the screenreader.Navigate using the keyboard only (expand)
- Ensure all links (navigation, text and/or image), form controls and page functions can be reached with the tab key in a logical order. - Ensure all links (navigation, text and/or image), form controls and page functions can be triggered with the spacebar, enter key, or arrow keys. - Ensure all interactive elements can be reached with the tab key in a logical order - Ensure all interactive elements can be triggered with the spacebar, enter key, or arrow keys. - Ensure focus is always visible and appears in logical order. - Ensure each interactive element has visible focus state which appears in logical order.How to configure this issue
product support
,analytics-insights
,operations
,service-design
,Console-Services
,tools-fe
)backend
,frontend
,devops
,design
,research
,product
,ia
,qa
,analytics
,contact center
,research
,accessibility
,content
)bug
,request
,discovery
,documentation
, etc.)