[Novo App Componentes] - Accessibility Bar

[vitorvlopes]

Goal

The Accessibility Bar aims to provide enhanced accessibility options for users with motor and visual impairments. Its primary goal is to ensure that all users, regardless of their physical abilities, can navigate and interact with our web application seamlessly. The bar offers features for navigation, and also can be improved to include more accessibility tools.

Context

Currently, our web application does not provide an intuitive way for users with disabilities to adjust the visual aspects or navigate through the interface using assistive technologies. Many users rely solely on keyboard navigation or screen readers, which can be challenging when interacting with complex web interfaces.

The Accessibility Bar will be hidden by default and activated through keyboard shortcuts, allowing for a minimal interface until needed. When activated, the bar will slide down from the top of the screen, offering options like "Go to Content". As users navigate through the bar using keyboard shortcuts, the selected button will be highlighted as the primary option, making it easier for users to identify the active element.

This proposal aligns with eMAG 3.1 Recommendation 1.5, which suggests that the first link on the page should be "Go to content" to facilitate faster navigation for users with screen readers or those navigating with the keyboard. By implementing this feature, we aim to make our application compliant with accessibility standards and provide a better experience for users with special needs.

Impact

Integrating the Accessibility Bar into our design system will introduce a new, standardized component that other teams and projects can leverage to ensure accessibility compliance. This component will be designed to seamlessly fit within our existing UI structure, while also allowing customization to match different design needs.

The introduction of the Accessibility Bar is expected to greatly improve the user experience for individuals with disabilities by offering them better control over how they interact with our websites. Users who rely on assistive technologies, such as screen readers or keyboard navigation, will benefit from the streamlined access to key features like content skipping.

Discussion Questions

What are the potential challenges in integrating the Accessibility Bar as a web (desktop) component into our existing design system?

Are there any technical constraints or compatibility issues we should be aware of with different browsers or frameworks?

Additional considerations

No response

Do you have a visual proposal?

https://www.figma.com/design/vFx484TqvzaXP3vMZX1UhF/Barra-de-Acessibilidade?node-id=0-1&t=H5GrYNIvqeNxKtY4-1

[andredelramo-hm]

Thanks, Vitor, for your comment 🙂
We'll review it with the accessibility team, and in the meantime, I add some questions that have come up:

• Is this something specific to Morga? We need to see how this applies in Europe.
• Are the links in the accessibility bar customizable?
• How is the accessibility bar functioning on mobile?
• What exactly is the accessibility menu? What options will it include?
• What will the keyboard shortcut be to activate it? Can it be customized?

[Ro-Matos]

Hello @andredelramo-hm, I can answer, I am participating in this project together with @vitorvlopes

• Is this something specific to Morga? We need to see how this applies in Europe.
  The accessibility bar is is not something specific to Morga, it related to WCAG criterion 2.4.1. Regarding Morga, the point is that the bar is a required feature.

• Are the links in the accessibility bar customizable?
  I think there could be a default version, with links like "Skip to content", "Skip to footer", "Skip to Search". However, they can be customized according to the need. The only link that is mandatory is "Skip to content", this must be the first link and could not be removed.

• How is the accessibility bar functioning on mobile?
  Beyond screen readers users, any user can use a keyboard connected to mobile devices, via USB or Bluetooth. The accessibility bar would work when activated via a keyboard or screen readers, regardless of the device, but mobile treatment is necessary if there is to be no layout break. Mobile version was included in the proposal.

• What exactly is the accessibility menu? What options will it include?
  The "Accessibility Menu" present in the proposal would be a customized link, it is not a resource belonging to the accessibility bar.

• What will the keyboard shortcut be to activate it? Can it be customized?
  The standard on the web is for the bar to be activated when navigating via the TAB key.

[andredelramo-hm]

Thank you very much for your comments @vitorvlopes @Ro-Matos 🙂
We have created a new issue to add the component. I leave the link here #1968

[Ro-Matos]

Thanks a lot @andredelramo-hm!
One thing to note is that this component is recommended for desktop and mobile (web). It is not usually used in APPs, and is not mentioned in APP legislations. However, the issue refers to Android and iOS tickets.
It might be interesting not to consider it for APPs, as this will also speed up development.

[aweell]

Thank you @Ro-Matos for the consideration, the checks are there because is the default template for issue creation.

We will update the issue as soon as we start working on it.

I close this discussion since there's already a related issue covering the topic.

[Ro-Matos]

All right @aweell!
Thanks!