Ihor Radchenko <yanta...@gmail.com> writes:
> Tim Cross <theophil...@gmail.com> writes: > >> Note that org also lacks any accessibility support for HTML generated >> documents as well. However, this is less problematic as authors do have >> some ability to add the necessary attributes that can improve >> accessibility - an option not available with Latex. > > Can we do anything about it? > Are there any available standards on how accessible HTML document should > look like? > > Unlike PDF where we rely on LaTeX, Org generates the final form of the > HTML documents. Hence, we have the full control (and responsibility) to > support accessibility. At least, as a customization. Yes, there are 2 standards/guidelines which are probably relevant for org mode - Web Content Accessibility Guide (WCAG v2) https://www.w3.org/WAI/standards-guidelines/wcag/glance/ and the - Authoring Tools Accessibility Guide (ATAG) https://www.w3.org/WAI/standards-guidelines/atag/ The first standard is about ensuring content is as accessible as possible. The second one is about ensuring authoring tools are accessible and on how authoring tools can be implemented to assist people in creating accessible content. It is this last goal which makes the second standard potentially relevant for org mode. There are also a number of tools out there which can be used to evaluate the accessibility of specific content. However, I find such tools are of limited benefit. The problem is, such tools rely heavily on conventions and heuristics. For example, they can alert you to images with no alt attribute. However, sometimes, not having an alt attribute actually improves accessibility (there is nothing worse than a web document which has alt tags on images used solely for formatting purposes!). The big difference between PDF and HTML is that HTML is essentially a 'tagged' format. In many respects, this makes it much easier. However, it also puts more responsibility on the author. >From an org-mode perspective, the key things which need to be maintained (and which perhaps we could make even easier or possibly have 'defaults') is the ability to add the alt attribute to any non-text element. For example, images, videos, sound files etc. All such content should always have some text describing the 'element'. However, it is also important to be able to not have an alt tag in some situations (for example, when using images as 'spacers' for formatting etc, we don't want an alt tag. Things to be aware of are things like using single characters or symbols (e.g. < and > for previous/next) or using unicode and other symbols whose meaning/purpose may seem very obvious when viewed, but is less so when 'spoken'. >From an authoring perspective, it probably would be good if org mode was able to alert the user to content which lacks an alt attribute but which probably should have one e.g. an image with no caption, a link to a video/audio file etc. One area which may need more investigation is with the rendering of tabular data. Having the correct tags (i.e. <td> for data and <th> for headings, is very important. Other areas which may need to be verified as being formatted correctly with adequate ARIA attributes are elements relating to navigation, indexing and referencing/footnotes. The big problems with accessibility in web content tend to come about from dynamic content, javascript and CSS. Plain HTML documents tend to be quite good provided the appropriate tags have been used. Where things become difficult is when you have content which is rendered based on dynamic variables - for example, content which is hidden/revealed via mouse clicks etc. The other important area often overlooked and which probably does need some work done is with keyboard navigation. As you can probably imagine, for blind and vision impaired users, the mouse cursor is a challenge and any web page which requires you to move the mouse and click on an element/link can be a challenge. having consistent keyboard navigation is important. THis is particularly relevant when dealing with data input via web forms etc. Of course, there is one very good way to assess the accessibility of a web page - use a screen reader and try navigating, browsing and reading some content with your eyes closed. If, for example, you find when hitting tab to move through 'elements' in the page that it is impossible to follow the structure or flow of the content (either because tab results in focus jumping to some unexpected location or because the internal link names used are too obscure or because there simply isn't sufficient contextual information, then there is an issue. The next step is to determine if this issue is because of how org mode is generating the output or because the author has used or failed to use appropriate alt tags etc. Note that all major platforms have free screen reader software available. For Apple and ChromeOS, it is part of the platform and just needs to be turned on. For windows, there is NVDA and for Linux there are a number of solutions, but Orca is probably a reasonable choice. There are also a number of browser extension modules which can add screen reader type functionality to chrome or firefox. I would encourage everyone to at least try using a screen reader to browse some content. Many of the concepts associated with accessibility can be difficult to appreciate without more context. Trying to browse a few web pages with a screen reader and your eyes closed can provide that context.
