For ADA, aria is generally advised to give that supplemental feedback to nonsighted viewers. Doing auto and manual testing upon implementing screen reading improvements can give you some clarity on how the supplemental text impacts the use of your app for those individuals using a screenreader.
Automated Testing: AX Tools was suggested as the automatic auditing software. Once you enable A11Y, those new ADA settings appear in each supported element and you can start building better, more compliant, tools for the public. By installing AX Tools extension and inspecting a web page in the extensions via browser's inspector window, you will be able to see what critical and non-critical warnings appear for your application.
Some false positives can show up and that is when you will want to shift to manual testing via NDVA. Specifically, you want to see exactly what order the screen reader explores your app. This is controlled through layout configuration on experience builder, but thereafter you can explore if certain elements give you problems like accordion elements, etc.
Manual Testing: NDVA is the suggested manual auditing software to audit a web app / experience builder app for compliance. The application is lightweight and configuration rich. You can have screen reading text show up in a dialog window to expedite review.
Anyways, I hope this helps. Take a look at this unofficial (non-ESRI) informational webpage from State of Massachussets. It pertains to the June EB Update for Aria: GIS accessibility guidance: Experience Builder | Mass.gov
I'd reference this, and follow up here if you had more quesitons about ARIA.
