dashorst opened a new issue, #1838: URL: https://github.com/apache/wicket/issues/1838
Wicket's components make no accessibility promise, and nobody knows how far they are from one. Outside the autocomplete and the upload field, wicket-core and wicket-extensions render no ARIA at all, and nothing in the build checks the markup they produce. This issue is the audit that sets the baseline: what each component renders today, measured against WCAG 2.2 level AA. WCAG conformance belongs to pages, not to libraries, so the goal is not "Wicket is WCAG compliant". The goal is that every component renders accessible markup by default and never stands in the way of an application that builds an accessible page. What remains the application's job (contrast, alternative texts, headings, the wording of labels and messages) is out of scope here, except where a component makes that job impossible or needlessly hard. ## Scope All components, behaviors and their default markup, JavaScript and CSS in `wicket-core` and `wicket-extensions` on `master`, including: - form components, `FormComponentLabel`, `FeedbackPanel` and form error reporting - links, buttons, `AjaxLink`/`AjaxButton`/`AjaxFallback*` and the elements they can be attached to - Ajax updates in general: focus after a component is replaced, busy state, the veil, announcements - `DataTable`, `AjaxFallbackDefaultDataTable`, headers and sorting, `PagingNavigator`/`AjaxPagingNavigator` - `ModalDialog`, `TabbedPanel`/`AjaxTabbedPanel`, tree components, `AutoCompleteTextField`, `Wizard`, `Palette`, upload fields and `UploadProgressBar`, date and time fields, `BreadCrumbBar`, `AjaxEditableLabel` and its variants, `AjaxLazyLoadPanel`, the indicating Ajax links and buttons, captcha images - page-level output Wicket controls, such as generated `<head>` contributions and error pages ## Method 1. A harness of test pages that renders each component in its common configurations, including the error and empty states. 2. An automated pass with axe-core over every harness page. 3. A manual keyboard pass: reachability, focus order, a visible focus indicator, no keyboard traps, focus after Ajax updates and dialogs. 4. Where a component implements a widget pattern (tabs, dialog, tree, combobox), a comparison with the WAI-ARIA Authoring Practices pattern. ## Deliverable A findings report with, for each finding: the component, what it renders, the WCAG 2.2 success criterion it fails, the severity (blocks use / hinders use / minor), the proposed fix, and whether the fix changes markup in a way applications could notice (CSS selectors, `TagTester` assertions). Findings that come from the application rather than the framework are listed separately with a note. The findings are grouped into slices that each become a follow-up issue: the framework fix, the reference documentation of what the component renders, a how-to and a runnable example with an automated accessibility check. Fixing is not part of this issue. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
