<div dir="ltr"><div dir="ltr">> My understanding is if a developer follow the WCAG standards and WAI-ARIA best practice then there should not be </div><div dir="ltr">> any issues with contents when it comes to using different AT, such as JAWS and NVDA. Is this correct?<br><div><br></div><div>In general, meeting the WCAG success criteria and following WAI-ARIA best practices should result in content that is functional with assistive technologies, such as JAWS and NVDA. That said, which browser is being used can have an impact on the actual user experience and so it is important to conduct manual testing to ensure the implemented code solution is indeed usable by an individual.</div><div><br></div><div>From my perspective, this means - follow the standards to develop/design the user interface and then perform manual testing using the assistive technology+browser combinations that are expected in the real world. If there are situations where the user experience fails (e.g., the screen-reader+browser combination do not result in an equivalent user experience), then you may need to try other combinations to evaluate if the code is the problem or if there is a bug with the AT product and/or browser.</div><div><br></div><div>But what should not happen - and this is what usually does happen - is that a specific AT+browser combination is decided upon in advance and then the user interface is written to specifically address that AT+browser combination. To developers and uninformed QA and Product Managers, everything "sounds good" and so the solution is considered "accessible." The difficulty is that to those developing such applications, the fact that the code works with JAWS = accessible and that is just not the reality.</div><div><br></div><div>Granted, there may be some specific situations in which you do have to create customized solutions...but with the use case you have identified with the labeling of form controls, both the native HTML solutions and WAI-ARIA techniques can result in code that is broadly accessible across multiple screen-reader and browser combinations.</div><div><br></div><div>Starting with accessibility standards instead selecting a specific AT+browser combination (and then only building around that combo), can result in a more accessible product overall.</div><div><br></div><div>Take care,</div><div>Sean</div></div></div>