AQuAMan

The last list item for Key Features and Functionality indicates a test is performed for missing accessibilityText parameter values. Note that no one should be relying on this test (the labels test is valid). Just because a component does not have accessibility text does not mean it fails any a11y requirement. In fact, accessibility text should not need to be used in most cases. It should only be used to provide additional information to non-sighted users. However, the need to do so is based on context. If you design your content correctly, accessibility text should never be needed. In cases where you may believe it IS needed, then you should consider redesigning your content so the information is available to all users, not just non-sighted users. The accessibilityText parameter is one of the most overused of Appian component parameters. In most cases where it is used, it either creates redundancy or confusion for users who rely on a screen reader. The parameter name is misleading because its use does not necessarily make content accessible or even "more accessible".

The last list item for Key Features and Functionality indicates a test is performed for missing accessibilityText parameter values. Note that no one should be relying on this test (the labels test is valid). Just because a component does not have accessibility text does not mean it fails any a11y requirement. In fact, accessibility text should not need to be used in most cases. It should only be used to provide additional information to non-sighted users. However, the need to do so is based on context. If you design your content correctly, accessibility text should never be needed. In cases where you may believe it IS needed, then you should consider redesigning your content so the information is available to all users, not just non-sighted users. The accessibilityText parameter is one of the most overused of Appian component parameters. In most cases where it is used, it either creates redundancy or confusion for users who rely on a screen reader. The parameter name is misleading because its use does not necessarily make content accessible or even "more accessible".

Hi Kurt Bunge  - thanks for adding this clarification. I've tried to articulate in the documentation that AQuAMan simply presents some findings (always expressed as "risks") and that it's entirely up to the user to establish what the risks are and whether what - if anything - should be done to address them. And, of course, context is key in any such  assessment.

In short: AQuAMan should not be used as a blunt tool where the findings are Boolean (good versus bad!) but as a source of insight from which actions may be taken.