AQuAMan

Overview

As 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

  • Automate 80% of the Peer Review checklist items
  • Register Appian applications and define common standards across that application
  • Run a suite of tests across an application patch
  • Report on failed tests
  • Copy tests between applications
  • Define new object/attribute tests (including database table and view objects) and apply within an application
  • Set the reported significance for a failed test (Fail/Warning/Information)
  • Report on unused variables in Expression Rules and Interfaces
  • Report on the complexity score for Expression Rules and Interfaces
  • Report on missing labels/accessibility text for Interface Object components

Anonymous
Parents
  • 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".

Comment
  • 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".

Children
  • Hi   - 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.