Issue
- When a form with a required checkbox field is submitted without the checkbox being selected, the corresponding <input> element in the DOM does not receive the
aria-invalid="true"attribute. - This behavior is perceived as an accessibility issue, especially when compared to other field types like text inputs, which do receive the attribute upon failed validation.
- The expected behavior is that the attribute would be added after a failed submission, as shown below:
Initial State:
<input type="checkbox" aria-required="true" ... >
Expected State After Failed Validation:
<input type="checkbox" aria-required="true" aria-invalid="true" ... >
Environment
- Liferay DXP 2024.Q3+
Resolution
This is the expected behavior and not considered a bug. After a detailed analysis, Liferay's Product Team has determined that the current implementation aligns with accessibility standards and best practices. No changes are planned for this behavior for the following reasons:
- Programmatic Association is Already in Place: The error message is programmatically linked to the checkbox group. This allows screen readers to detect and announce the error when a user focuses on the group’s first item, fulfilling accessibility requirements for error identification.
-
Alignment with Industry Standards: The current approach is consistent with common accessibility practices, including those used by the W3C's own design system and other accessible services like GOV.UK. These examples also indicate errors at the group level rather than applying
aria-invalidto individual checkboxes within a group. -
Risk of User Confusion: Applying
aria-invalidto individual options within a checkbox group (especially for Yes/No selections) can create misleading feedback. A screen reader might announce each option as “invalid,” confusing the user into thinking all choices are incorrect rather than understanding that a selection is required from the group.
Based on the principle of "No ARIA is better than bad ARIA," introducing the aria-invalid attribute in this context is not recommended as it could negatively impact the user experience. Internal validation using automated tools (Axe, Wave, Lighthouse) and manual testing with screen readers (JAWS, NVDA, VoiceOver) has confirmed that the current implementation complies with accessibility standards.