A library of reusable components, patterns, and examples that embrace modern product design practices. Additionally, a collection of in-house standards, guidelines, and principles for creating inclusive, user-friendly, and effective products and services.
The following accessibility issues were picked up by Mark, who was reviewing the code a bit more in-depth than we were able to. We will defer to his recommendations as he's also picked up some design related issues that were related to decisions we had made.
Components
[x] Accordions: Possibly add an example of the accordion being used with a definition list?
[ ] Alerts: I would recommend incorporating the svgs into the sass to simplify markup.
[x] Buttons: This is a general comment on close buttons, they are always empty which will flag up in some accessibility checks even with the aria-label. I am not sure what is best practice, I tend to use hidden text but there does not seem to be a consensus on best practice.
[x] Cards: Very minor, I think the card title and subtitle should be an hgroup
[x] Checkboxes & radios: The examples of grouped checkboxes/radios should be in a fieldset or aria group.
[x] Progress indicators: The percentile bar needs an aria-label or aria-labelledby if a visible label is required.
[x] Progress - step indicator: On the step progress, I am not sure if there is any value in letting a screen reader read out every step before the current step. I would probably use aria-hidden. They should also be a list and giving each step the role progress bar is incoreect as that makes each step it's own progress bar.
[x] Quotes: I am not sure is appropriate. The caption should be a .
[x] Select: The no value option should be worded better like "Please select"
[x] Textarea: In the example, both labels have the same id in the for attribute.
[ ] Validation/Alerts: Very minor notes for the example:-The SVG could be embedded in the css to simplify the code. Example code could be simpler - the row and col classes don't actualy do anything as 12 col width are the default.
[ ] Validation: Ideally, the items should list to page anchors for the field in error. We have had this reported to us by accessibility testers but they let us pass with out it as we had difficulty implementing this in code.
Patterns
[x] Addresses: The postcode in the example overflows in mobile as it has a minimum width set by the w-50 class. It might be an idea to have a postcode class to ensue they are consistent width.
[x] **Date picker: Date Picker is always 320px wide and it's position is set to the left most position of the control, it can be cut off in mobile view.
[x] Filters: The whitespace needs to be set on this element
[x] Footer: The full class does not seem to do anything
[ ] Hero: This
should probably be a
[x] Login / Signup: inputs should have aria-required
[x] Pagination: No current page indicator, could overflow on small screens/large amount of items
[x] Search: The search button should have readable but visually hidden text
[x] Headers / menus: Left padding on the large version seems too large
The following accessibility issues were picked up by Mark, who was reviewing the code a bit more in-depth than we were able to. We will defer to his recommendations as he's also picked up some design related issues that were related to decisions we had made.
Components
Patterns