Accessibility Guides #360
Accessibility Guides #360
Conversation
|
This pull request is automatically being deployed by Amplify Hosting (learn more). |
|
|
||
| But simply **using the Norton Design System will not guarantee that an application or its content will be accessible**. | ||
| In fact, a significant portion of an accessible user experience depends on factors that the Norton Design System either cannot or should not control. | ||
| In general, these include how the application composes design system foundations and components together, and the accessibility of the content itself. |
There was a problem hiding this comment.
Accessibility is a shared responsibility between the design system and the application developers.
| 1. Build for accessibility first | ||
| 1. Provide guarantees about our internals | ||
| 1. Make the right thing the easy thing | ||
|
|
There was a problem hiding this comment.
- Prioritize user feedback and continuous improvement.
- Ensure compatibility with assistive technologies
| But we can't guarantee how our button is used since that is inherently _external_ to the design system. | ||
| For instance, there is nothing stopping a design system user from using our button to navigate between pages. | ||
| We advise against this since using a [Link](/docs/components/link) is the best way to make navigation accessible, but we can't and won't prevent it. | ||
| ::: |
There was a problem hiding this comment.
It is essential that developers understand the best practices for using each component to maintain accessibility.
|
|
||
| :::note Enforced accessibility vs. Reasonable defaults | ||
| Whenever possible, the Norton Design System will enforce accessibility requirements within its React implementation, but these instances are surprisingly rare. | ||
| Most often, we provide what is often called "reasonable defaults": default values that can be changed if necessary, but will work for most cases out of the box. |
There was a problem hiding this comment.
Additionally, we ensure our components are tested with various assistive technologies to confirm their accessibility.
| - **Reasonable default**: [tooltips](https://wwnorton.github.io/design-system/docs/components/tooltip) have a `trigger` prop that controls when the tooltip is opened and defaults to `focus pointerenter`. | ||
| This causes the tooltip to appear when users focus the tooltipped element (either with a mouse or a keyboard), or when they hover over it with [all pointers](https://developer.mozilla.org/en-US/docs/Web/API/PointerEvent/pointerType) (mouse, stylus, finger)—a reasonable assumption for the default behavior. | ||
| But if an application author wants to explicitly require another action to open the tooltip such as on click, they can customize this. | ||
| ::: |
There was a problem hiding this comment.
Ensuring Compatibility with Assistive Technologies
The Norton Design System is committed to ensuring compatibility with a wide range of assistive technologies. This includes screen readers, voice control software, switch devices, and more. We perform extensive testing with various tools to identify and resolve any accessibility issues.
Continuous Improvement and User Feedback
Accessibility is an ongoing process that benefits greatly from user feedback. We actively seek input from users with disabilities to understand their experiences and improve our design system. Regular updates and enhancements are made based on this feedback, ensuring that our components remain accessible and user-friendly.
This adds a new set of guides around accessibility.
Closes NDS-445.