Move component checks to the Native side

[ceceppa]

Is there an existing issue for this?

• I have searched the existing issues

Code of Conduct

• I agree to follow this project's Code of Conduct

Feature Request

Description

Accessibility checks are now primarily performed on the native side, allowing users to rely directly on our custom components (such as Pressable, Text, etc.) for immediate feedback about common accessibility issues. Additionally, this change ensures broader compatibility, allowing the library to integrate seamlessly with any other React Native UI library.

A new Playground app has also been added, providing users a hands-on environment to explore the library’s capabilities, better understand accessibility issues identified by AMA, and practice fixing them interactively.

Extras

• Move each extra component in a separate package.
  • BottomSheet
• Make each separate container independent of the core
  • Use console.error for failed checks, if core is not available

Feedback View

• Visual feedback of the offending components
• Allow the user to scroll through the error and warnings
• Popup informs the user on the issue and how to fix it

TODO

• Add a thick border for the popup using the same color of the severity

Checks

Pressable

• No a11y label
• No a11y role
• Size too small
• Contrast
• No "pressed" callback + no disabled?

Text

• Contrast
• Long numbers, i.e. Possibile phone number or bank account?

Headers

• Missing headers: No headers in the current screen

UI Interaction

Check if is possible to hijack pressable events to see if its triggering did cause some UI change. For example some new element appeared or changed...
This could allow AMA to possible detect:

• Missing aria status on the component
• Missing focus change

Forms

• Missing Label
• Missing label during onChange?
• Keyboard trap

[pietgk]

@ceceppa i am trying to run the playground and propably did somethings wrong.
i had to make chages to get it working on my machine.
feel free to look at my draft pr to get an impression of the issues i had.
#325

[ceceppa]

The main branch is somewhat broken, meaning it has issues with lint and tests. But you should be able to compile the playground app for iOS and Android.

Can you provide a log for the iOS?

[pietgk]

@ceceppa

i can build the playground so im good regarding that.

i see you merged stuff from my draft pr :-)

in our project where we want to use AMA we are using expo and storybook (web and native).

i had to make changes to support react-native-web (extend web stuff to match native).

if you want to also support web then i can try to do that in this repo instead of only in our code.

but that would probably mean adding storybook to this repo, and adding the code that makes AMA cmponents run in rn web.

any preferences or limitations or other things i need to consider before trying to do this?

See issue #322 for some (to much) details.

--piet

[ceceppa]

i can build the playground so im good regarding that.

That sounds good :)

i see you merged stuff from my draft pr :-)

Yes, there were some changes that I needed. Also, it was easier to merge before pushing some changes on my side that would have caused merge conflicts.

in our project where we want to use AMA we are using expo and storybook (web and native).
i had to make changes to support react-native-web (extend web stuff to match native).
if you want to also support web then i can try to do that in this repo instead of only in our code.
but that would probably mean adding storybook to this repo, and adding the code that makes AMA cmponents run in rn web.
any preferences or limitations or other things i need to consider before trying to do this?

I don't have experience in using react native for web, so any help is welcome.
However, my current timeline is:

• Move most of the checks done in the @react-native-ama/react-native package on the native side
• I'll then remove the Pressable, Text and Touchable components from that package
• I'm also planning to further split the current packages to:
  1. make them independent from the core
  2. allow users to install small packages that they need

This is roughly what is going to happen in the next months. There will be some significant changes to the codebase, and I'm unsure whether adding Storybook support now is a good idea or if it would be better to delay it.

If you think that working in parallel is feasible, you could open a PR and I'll be pushing change against that.

Also, I'd appreciate feedback on the library, especially any pain points.

[pietgk]

ok, thx for the feedback.
i got storybook working on the native side and i am looking into fixing the issues i have for react-native-web
i need to get this working to be able to integrate AMA components into our repo as we use storybook for native and web

ill create a pr as soon is i got it working

in parallel i started looking into proper voice over wth hierarchy support together with a colleague of mine.
this will probably be needing native code to get anything useful.
ill keep you in the loop.