From: Jude DaShiell <jdashiel@panix.com>
To: Tim Cross <theophilusx@gmail.com>, Ihor Radchenko <yantar92@gmail.com>
Cc: Timothy <orgmode@tec.tecosaur.net>, emacs-orgmode@gnu.org
Subject: Re: Org HTML export accessibility (was: org exported pdf files)
Date: Thu, 29 Sep 2022 07:43:13 -0400 [thread overview]
Message-ID: <91c099ef-da41-b84-e1a2-bdc5b6da3dba@panix.com> (raw)
In-Reply-To: <86pmfeo4os.fsf@gmail.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.
>
>
next prev parent reply other threads:[~2022-09-29 13:41 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-27 1:48 org exported pdf files Jude DaShiell
2022-09-27 2:48 ` Ihor Radchenko
2022-09-27 3:15 ` Jude DaShiell
2022-09-27 3:24 ` Ihor Radchenko
2022-09-27 4:31 ` Jude DaShiell
2022-09-27 4:58 ` Ihor Radchenko
2022-09-28 4:36 ` Jude DaShiell
2022-09-28 4:53 ` Timothy
2022-09-28 6:48 ` Jude DaShiell
2022-09-28 8:47 ` Tim Cross
2022-09-28 9:19 ` Timothy
2022-09-28 17:08 ` Tim Cross
2022-09-28 17:39 ` Timothy
2022-09-28 18:23 ` Juan Manuel Macías
2022-09-29 20:58 ` Tim Cross
2022-09-29 4:09 ` Org HTML export accessibility (was: org exported pdf files) Ihor Radchenko
2022-09-29 8:22 ` Tim Cross
2022-09-29 11:43 ` Jude DaShiell [this message]
2022-09-29 21:05 ` Apology [was: Re: Org HTML export accessibility (was: org exported pdf files)) Tim Cross
2022-09-30 5:34 ` tomas
2022-10-02 10:59 ` Apology [ Fraga, Eric
2022-10-02 9:42 ` [HELP] Help implementing org-lint/warnings buffer during export (was: Org HTML export accessibility (was: org exported pdf files)) Ihor Radchenko
2022-10-02 20:52 ` Tim Cross
2022-10-03 3:25 ` Ihor Radchenko
2022-09-29 7:07 ` org exported pdf files Max Nikulin
2022-09-29 21:00 ` Tim Cross
2022-10-01 10:55 ` Max Nikulin
2022-09-28 13:02 ` Jude DaShiell
2022-09-28 16:12 ` Max Nikulin
2022-09-27 11:08 ` Max Nikulin
2022-09-28 3:07 ` Ihor Radchenko
2022-09-28 15:58 ` Max Nikulin
2022-09-29 4:12 ` Add \usepackage{cmap} as default LaTeX class in ox-latex (was: org exported pdf files) Ihor Radchenko
2022-09-29 15:34 ` Max Nikulin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=91c099ef-da41-b84-e1a2-bdc5b6da3dba@panix.com \
--to=jdashiel@panix.com \
--cc=emacs-orgmode@gnu.org \
--cc=orgmode@tec.tecosaur.net \
--cc=theophilusx@gmail.com \
--cc=yantar92@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).