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

[Tim Cross]

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.