One thing I vividly remember doing Navy mandatory trainings was several instances when providers had mouse cursor and keyboard disabled so the only way to proceed was to have a sighted person position and click the physical mouse!
Jude <jdashiel at panix dot com> "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) . On Thu, 29 Sep 2022, Tim Cross wrote: > > 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. > >
