It's better when it's simple

User Tools

Site Tools



Accessibility is to make things work for everyone, including people with various disabilities and impairments.

It is also part of many countries' legislation. There is the Web Accessibility Directive in all EU countries, Americans with Disabilities Act (ADA) and Section 508 in the US and lots of others.

Most of those laws or policies require a website to meet the Web Content Accessibility Guidelines (WCAG) 2.1 AA or a version of it. Therefore, knowing how compliant something is to WCAG can be a big advantage and the reason why some software might be used/procured/recommended and others might not.

Just because something is WCAG compliant doesn't mean there are no barriers and you're not excluding anyone, but it is a good start and internationally acknowledged.

How accessible is DokuWiki?

A DokuWiki instance is made up of at least the core engine, the content you put into the wiki and optionally some extensions (plugins and maybe a different template). All of those will have different levels of accessibility.

Core engine

The Hogfather version of the core engine with the default template and no plugins was audited for WCAG compliance in March 2021. The WCAG audit report shows that DokuWiki is currently not WCAG compliant.

You can follow the progress of the issues raised or even help out fixing them at the 'Accessibility Audit' project on GitHub.


There is currently no way of knowing if the extensions you use are accessible or not, other than auditing them yourself.

It would be good if there was a consistent way for plugin and template authors to at least self-declare the level of accessibility.


Even with a fully compliant core engine, the content that you put into the wiki can still cause accessibility issues and make your wiki not compliant.

Here are a few tips on how to make sure the content of your wiki stays as accessible as possible:

  • Make sure to only use the formatting as intended so the correct semantics are used. For example, don't use headings for making something big and bold if it's not meant to be a heading. Don't use a table to highlight some text.
  • Give links a text that makes their purpose clear.
  • Headings should accurately describe their topic or purpose.
  • Headings should ideally not skip any levels in their hierarchy and together reflect what the page is about. For example, make sure after a heading level 3 only follows a heading level 2, 3 or 4.
  • The page title (the text that labels browser tabs) should describe topic or purpose of the main page content. That can be achieved with the 'useheading' config option as that uses the first heading of the main content for the page title.
  • Give images that are not decorative an alternative text that conveys the same meaning as the image. The alternative text can either be added to the image syntax itself, for example {{file.png|alternative text}}, or it can be described in the text above or below.
  • But always add alternative text via the syntax if that image is also within a link and there is no other text in the link. It should then describe the purpose of the link.
  • Videos should have captions and audio descriptions (if there are meaningful visuals that are not already described in the video).
  • Make sure to declare the correct language. When your wiki contains pages in different languages, the Translation plugin does that (but only if the 'translateui' option is used). When your wiki contains different languages within the same page, the Wrap plugin does that with the language syntax. For example, <wrap :en>This text is explicitly marked as English.</wrap>.
accessibility.txt · Last modified: 2024-02-28 09:16 by saggi

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki