Re: Org HTML export accessibility (was: org exported pdf files)

[Jude DaShiell <jdashiel@panix.com>]

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 <yantar92@gmail.com> writes:
>
> > Tim Cross <theophilusx@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.
>
>