diff --git a/docs/contributing/developing.rst b/docs/contributing/developing.rst index 5b58f67d22..f77ef7c294 100644 --- a/docs/contributing/developing.rst +++ b/docs/contributing/developing.rst @@ -190,20 +190,23 @@ Accessibility targets We want to make Wagtail accessible for users of a wide variety of assistive technologies. The specific standard we aim for is `WCAG2.1 `_, AA level. Wagtail’s administration user interface isn’t accessible at the moment (see `issue #4199 `_), but here are specific assistive technologies we aim to test for, and ultimately support: -===================================================================================================================== -Assistive technology -===================================================================================================================== -Screen reader: `NVDA `_ on Windows with Firefox ESR -Screen reader: `VoiceOver `_ on macOS with Safari -Magnification: `Windows Magnifier `_ -Magnification: macOS Zoom -Voice control: Windows Speech Recognition -Voice control: macOS Dictation +============= ==================== +Type Assistive technology +============= ==================== +Screen reader `NVDA `_ on Windows with Firefox ESR +Screen reader `VoiceOver `_ on macOS with Safari +Magnification `Windows Magnifier `_ +Magnification macOS Zoom +Voice control Windows Speech Recognition +Voice control macOS Dictation +Screen reader Mobile `VoiceOver `_ on iOS, or `TalkBack `_ on Android +============= ==================== -We aim for Wagtail to work in those environments. Our development standards ensure that the site is usable with other assistive technologies. In practice, testing with assistive technology can be daunting for newcomers – here are browser extensions that can help identify accessibility issues, to use during development: +We aim for Wagtail to work in those environments. Our development standards ensure that the site is usable with other assistive technologies. In practice, testing with assistive technology can be a daunting task that requires specialised training – here are tools we rely on to help identify accessibility issues, to use during development and code reviews: -* `Axe `_ for automated tests of a given page. -* `Accessibility Insights for Web `_ for semi-automated tools, and manual audits. +* `react-axe `_ integrated directly in our build tools, to identify actionable issues. Logs its results in the browser console. +* `Axe `_ Chrome extension for more comprehensive automated tests of a given page. +* `Accessibility Insights for Web `_ Chrome extension for semi-automated tests, and manual audits. Compiling static assets ~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/docs/contributing/html_guidelines.rst b/docs/contributing/html_guidelines.rst index c6640b75f2..85f3c34f76 100644 --- a/docs/contributing/html_guidelines.rst +++ b/docs/contributing/html_guidelines.rst @@ -12,5 +12,6 @@ Principles ~~~~~~~~~~ * Write `valid HTML `_. We target the HTML5 doctype. +* Write `semantic HTML `_. * Attach JavaScript behavior with ``data-`` attributes, rather than classes or IDs. * For comments, use Django templates syntax instead of HTML.