OverviewAs a Peer Reviewer I want to have a fast and predictable method of checking the quality of application patches so that I do not have to exert a lot of time and energy manually checking these against the application standards.
As a Lead Developer I want to define and manage the quality standards that comprise the 'Definition of Good' for my application so that they can be applied and reported on in a peer review against an application patch.
Key Features & Functionality
Report on missing labels/accessibility text for Interface Object components
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".