org exported pdf files

org exported pdf files

[Jude DaShiell]

can these files include the language attribute like what happens in
microsoft word?  If yes, and the contents are text that would go a long
way to making those pdf files screen-reader accessible.



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)

.

Re: org exported pdf files

[Ihor Radchenko]

Jude DaShiell <jdashiel@panix.com> writes:

> can these files include the language attribute like what happens in
> microsoft word?

AFAIK, yes. See org-latex-hyperref-template

> If yes, and the contents are text that would go a long
> way to making those pdf files screen-reader accessible.

Have you tried Org-exported pdfs on screen-reader?
(I haven't, so I am curious to see if there are any improvements we can
make in this area).

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: org exported pdf files

[Jude DaShiell]

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 Tue, 27 Sep 2022, Ihor Radchenko wrote:

> Jude DaShiell <jdashiel@panix.com> writes:
>
> > can these files include the language attribute like what happens in
> > microsoft word?
>
> AFAIK, yes. See org-latex-hyperref-template
>
> > If yes, and the contents are text that would go a long
> > way to making those pdf files screen-reader accessible.
>
> Have you tried Org-exported pdfs on screen-reader?
> (I haven't, so I am curious to see if there are any improvements we can
> make in this area).
>
Not yet, but that will be on my list.  Is that latex template
automatically used by orgmode when doing a pdf export or is code needed
in some file to pull it in?
>

Re: org exported pdf files

[Ihor Radchenko]

Jude DaShiell <jdashiel@panix.com> writes:

>> Have you tried Org-exported pdfs on screen-reader?
>> (I haven't, so I am curious to see if there are any improvements we can
>> make in this area).
>>
> Not yet, but that will be on my list.  Is that latex template
> automatically used by orgmode when doing a pdf export or is code needed
> in some file to pull it in?

Yes, the template is used by default. You can also control what is
filled in there in export settings (see 13.10.2 LaTeX specific export settings)

And, of course, you can override/extend it if necessary.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: org exported pdf files

[Jude DaShiell]

Having examined 13.10.2, with the polyglossia package installed and
accessible to orgmode putting set-language into the right place would
default to English and other languages would need to specify their
language for a pdf export.  On Linux I have espeak-ng running as default
and I run orca as necessary.  I mostly live on the command line so orca is
used rarely.
I think a reasonable test of export quality will be to make a pdf with
orgmode then run that pdf through pdftotext and compare the extracted text
with the pdf file.  I can't do that since without use of pdftotext the
screen readers will not work on pdf files.



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 Tue, 27 Sep 2022, Ihor Radchenko wrote:

> Jude DaShiell <jdashiel@panix.com> writes:
>
> >> Have you tried Org-exported pdfs on screen-reader?
> >> (I haven't, so I am curious to see if there are any improvements we can
> >> make in this area).
> >>
> > Not yet, but that will be on my list.  Is that latex template
> > automatically used by orgmode when doing a pdf export or is code needed
> > in some file to pull it in?
>
> Yes, the template is used by default. You can also control what is
> filled in there in export settings (see 13.10.2 LaTeX specific export settings)
>
> And, of course, you can override/extend it if necessary.
>
>

Re: org exported pdf files

[Ihor Radchenko]

Jude DaShiell <jdashiel@panix.com> writes:

> Having examined 13.10.2, with the polyglossia package installed and
> accessible to orgmode putting set-language into the right place would
> default to English and other languages would need to specify their
> language for a pdf export.

The default can be changed in your Emacs configuration. Check out
org-export-default-language.

> On Linux I have espeak-ng running as default
> and I run orca as necessary.  I mostly live on the command line so orca is
> used rarely.
> I think a reasonable test of export quality will be to make a pdf with
> orgmode then run that pdf through pdftotext and compare the extracted text
> with the pdf file.  I can't do that since without use of pdftotext the
> screen readers will not work on pdf files.

I checked on of my exported PDFs, and it looks mostly consistent with the
org source from a brief look. The only minor deficiency is sparkled text
from included vector images with text, but I imagine that it is common
and may or may not be a real deficiency.

Do note that Org to PDF export works by first exporting to a .tex file
and then running TeX. As long as TeX makes a decent job with PDF
accessibility, we should be good to go. Just need to make sure that we
pass the correct options to TeX in the generated .tex file.

You mentioned that one of the TeX options is setting the correct
metadata. I am not aware about other required options that can improve
accessibility. If you know any, feel free to share.

Also, you can refer to our previous discussion about accessibility of
documents exported by Org.
https://list.orgmode.org/orgmode/87czew3w5l.fsf@localhost/

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: org exported pdf files

[Max Nikulin]

On 27/09/2022 11:31, Jude DaShiell wrote:
> Having examined 13.10.2, with the polyglossia package installed and
> accessible to orgmode putting set-language into the right place would
> default to English and other languages would need to specify their
> language for a pdf export.  On Linux I have espeak-ng running as default
> and I run orca as necessary.  I mostly live on the command line so orca is
> used rarely.
> I think a reasonable test of export quality will be to make a pdf with
> orgmode then run that pdf through pdftotext and compare the extracted text
> with the pdf file.  I can't do that since without use of pdftotext the
> screen readers will not work on pdf files.

At first I expected that you may use some proprietary screenreader 
software, e.g. some plugin to Adobe Reader.

Could you, please, provide a tiny example of your Org file with just a 
couple of lines of text and with settings relevant to export? It would 
be helpful to get an example of minimal LaTeX file that allows to 
generate a PDF file that has metadata that you expect to get and the PDF 
file or at least output of pdfinfo, pdffonts.

There are still enough of uncertainties:
- What TeX engine do you use? E.g. for PdfLaTeX it may be necessary to 
add \usepackage{cmap} immediately after \documentclass. Unicode engines 
like LuaTeX likely do not require such trick.
- Is there a reason why you are using polyglossia? Juan Manuel on this 
list says that (if I have got it right) babel is superior nowadays.
- There may be some LaTeX-related specifics for particular language 
after all.

Re: org exported pdf files

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> - What TeX engine do you use? E.g. for PdfLaTeX it may be necessary to 
> add \usepackage{cmap} immediately after \documentclass. Unicode engines 
> like LuaTeX likely do not require such trick.

I am wondering if having cmap should be a good default in general.
Not just for accessibility.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: org exported pdf files

[Jude DaShiell]

I checked that out and putting the example text into my .emacs file
generates a warning when emacs starts up  I put the parens and everything
between the parens in the .emacs file and that caused the warning to be
thrown.
What may work and circumvent all of this would be to add:
#+LANGUAGE: en
into a text source file which is part of the files exported through
orgmode pdf.
Adobe has plenty of pdf accessibility guidelines available for those
interested in accessibility to implement.
if those #+ items are called orgmode-directives maybe an
orgmode-accessibility directive could be used at minimum to put the
system's default org-export-language directive into that source text file
that goes into the pdf file.
I have done nothing with exporting to pdf from orgmode since several years
ago I was told orgmode pdf's were not accessible.



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 Tue, 27 Sep 2022, Ihor Radchenko wrote:

> Jude DaShiell <jdashiel@panix.com> writes:
>
> > Having examined 13.10.2, with the polyglossia package installed and
> > accessible to orgmode putting set-language into the right place would
> > default to English and other languages would need to specify their
> > language for a pdf export.
>
> The default can be changed in your Emacs configuration. Check out
> org-export-default-language.
>
> > On Linux I have espeak-ng running as default
> > and I run orca as necessary.  I mostly live on the command line so orca is
> > used rarely.
> > I think a reasonable test of export quality will be to make a pdf with
> > orgmode then run that pdf through pdftotext and compare the extracted text
> > with the pdf file.  I can't do that since without use of pdftotext the
> > screen readers will not work on pdf files.
>
> I checked on of my exported PDFs, and it looks mostly consistent with the
> org source from a brief look. The only minor deficiency is sparkled text
> from included vector images with text, but I imagine that it is common
> and may or may not be a real deficiency.
>
> Do note that Org to PDF export works by first exporting to a .tex file
> and then running TeX. As long as TeX makes a decent job with PDF
> accessibility, we should be good to go. Just need to make sure that we
> pass the correct options to TeX in the generated .tex file.
>
> You mentioned that one of the TeX options is setting the correct
> metadata. I am not aware about other required options that can improve
> accessibility. If you know any, feel free to share.
>
> Also, you can refer to our previous discussion about accessibility of
> documents exported by Org.
> https://list.orgmode.org/orgmode/87czew3w5l.fsf@localhost/
>
>

Re: org exported pdf files

[Timothy]

[-- Attachment #1: Type: text/plain, Size: 245 bytes --]

Hi Jude,

> I have done nothing with exporting to pdf from orgmode since several years
> ago I was told orgmode pdf’s were not accessible.

Do you know where this information came from? And what do you use now?

All the best,
Timothy

Re: org exported pdf files

[Jude DaShiell]

It was one of the messages from this list that got me that reply.  For
now, when I get a pdf file I try extracting it with pdftotext and read the
extracted text.  I don't make pdf files or make pdf files available for
anyone else.  How adobe accessibility recommendations for pdf files will
translate to Linux I don't know many were geared toward windows if memory
serves.  I haven't used windows since 2013 and don't intend using windows
for the duration either.



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 Wed, 28 Sep 2022, Timothy wrote:

> Hi Jude,
>
> > I have done nothing with exporting to pdf from orgmode since several years
> > ago I was told orgmode pdf?s were not accessible.
>
> Do you know where this information came from? And what do you use now?
>
> All the best,
> Timothy
>

Re: org exported pdf files

[Tim Cross]

Jude DaShiell <jdashiel@panix.com> writes:

> It was one of the messages from this list that got me that reply.  For
> now, when I get a pdf file I try extracting it with pdftotext and read the
> extracted text.  I don't make pdf files or make pdf files available for
> anyone else.  How adobe accessibility recommendations for pdf files will
> translate to Linux I don't know many were geared toward windows if memory
> serves.  I haven't used windows since 2013 and don't intend using windows
> for the duration either.
>

The problem is not with org mode, but rather with the limitations of
Latex. The basic problem is that latex pre-dates accessibility concerns
and lacks full support for tagging, alt text and other document
structure information necessary to make PDF files accessible. Adding a
language environment setting will have only minimal benefit. It is the
tagging and other structural information which is necessary to make
things really accessible i.e. the ability to browse a PDF document and
retain the structural relationships within the document and use that
information in a meaningful way - consider for example, browsing data
inside a table within a PDF document.

There are accessibility working groups within the tex/latex community
who have been working on trying to improve accessibility of documents
created using latex and some progress has been made. However, it is
nowhere near the same level of sophistication as supported by other PDF
generators, like adobe's suite, which has very good accessibility
support and can enable production of some of the best accessible
documents I've used.

There are a couple of additional latex packages which can be added to
documents which will provide some tagging and other structural
information which will significantly improve the accessibility of PDF
documents. I've not tested these with different engines.

https://ctan.org/pkg/accessibility?lang=en

and you would want ot add

\usepackage[tagged, highstructure]{accessibility}

to your packages list.

To add accessibility for math formulas etc, you need

https://ctan.org/pkg/axessibility?lang=en

and add

\usepackage{axessibility}

As with other authoring, you also need to consider accessibility
requirements when creating your documents and do things like adding \alt
textg for figures etc.

It would probably be good to add the two above packages as part of the
'default' package preamble, but this would require considerable testing
as it isn't known if there will be adverse effects when mixed with other
packages.

Re: org exported pdf files

[Timothy]

[-- Attachment #1: Type: text/plain, Size: 2133 bytes --]

Hi Tim,

> It would probably be good to add the two above packages as part of the
> ’default’ package preamble, but this would require considerable testing
> as it isn’t known if there will be adverse effects when mixed with other
> packages.

Those packages are early accessibility experiments, and are /not/ intended for
wider use. See the top of the <https://github.com/AndyClifton/accessibility>
README: “Prototype. Not suitable for production”.  The author themselves said in
a [2020 tex.SE answer] that:

      `accessibility' was developed and published back in 2007 as a proof of concept for
      some of the KOMA document styles. I got hold of the files from the author in
      2019 and took over maintenance with her permission. I tidied up the package
      enough to get it to CTAN, but didn’t update the functionality. I also published
      it to GitHub to get some feedback on it.

      It seems to have worked well in 2007 for a few test cases. Unfortunately it now
      fails every test case, and it looks like needing some serious efforts to fix.

      Because of this I no longer think that accessibility is fit for purpose.

They also go on to make a comment I’ve seen a few times from the people working
on the latex3 accessibility project — basically that in order to actually get
a /good/ solution, we’ll need to wait till support is baked into the LaTeX core.

If we’re desperate to add this, we’ll likely want to look at `tagpdf' which is
written by someone working on the latex3 accessibility project. It is apparently
capable of passing PCA3, however according to the author:

      `tagpdf' hasn’t been written as a user package but to allow experiments and tests
      and to help to identify missing interfaces in the kernel and in packages. It can
      change at any time in incompatible ways and it requires some skills to use it.

So, while it may be a particularly boring answer, I think “wait and see” is our
current best bet.

All the best,
Timothy


[2020 tex.SE answer] <https://tex.stackexchange.com/a/551287/167605>

Re: org exported pdf files

[Jude DaShiell]

I've never done anything with latex.  The closest I got to latex was using
groff for a little bit of time a long time ago.  On this one I'm in way
over my head without scuba gear.  Apparently html and adobe left latex in
the dust in so far as accessibility is concerned.



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 Wed, 28 Sep 2022, Tim Cross wrote:

>
> Jude DaShiell <jdashiel@panix.com> writes:
>
> > It was one of the messages from this list that got me that reply.  For
> > now, when I get a pdf file I try extracting it with pdftotext and read the
> > extracted text.  I don't make pdf files or make pdf files available for
> > anyone else.  How adobe accessibility recommendations for pdf files will
> > translate to Linux I don't know many were geared toward windows if memory
> > serves.  I haven't used windows since 2013 and don't intend using windows
> > for the duration either.
> >
>
> The problem is not with org mode, but rather with the limitations of
> Latex. The basic problem is that latex pre-dates accessibility concerns
> and lacks full support for tagging, alt text and other document
> structure information necessary to make PDF files accessible. Adding a
> language environment setting will have only minimal benefit. It is the
> tagging and other structural information which is necessary to make
> things really accessible i.e. the ability to browse a PDF document and
> retain the structural relationships within the document and use that
> information in a meaningful way - consider for example, browsing data
> inside a table within a PDF document.
>
> There are accessibility working groups within the tex/latex community
> who have been working on trying to improve accessibility of documents
> created using latex and some progress has been made. However, it is
> nowhere near the same level of sophistication as supported by other PDF
> generators, like adobe's suite, which has very good accessibility
> support and can enable production of some of the best accessible
> documents I've used.
>
> There are a couple of additional latex packages which can be added to
> documents which will provide some tagging and other structural
> information which will significantly improve the accessibility of PDF
> documents. I've not tested these with different engines.
>
> https://ctan.org/pkg/accessibility?lang=en
>
> and you would want ot add
>
> \usepackage[tagged, highstructure]{accessibility}
>
> to your packages list.
>
> To add accessibility for math formulas etc, you need
>
> https://ctan.org/pkg/axessibility?lang=en
>
> and add
>
> \usepackage{axessibility}
>
> As with other authoring, you also need to consider accessibility
> requirements when creating your documents and do things like adding \alt
> textg for figures etc.
>
> It would probably be good to add the two above packages as part of the
> 'default' package preamble, but this would require considerable testing
> as it isn't known if there will be adverse effects when mixed with other
> packages.
>
>
>

Re: org exported pdf files

[Max Nikulin]

On 28/09/2022 10:07, Ihor Radchenko wrote:
> Max Nikulin writes:
> 
>> - What TeX engine do you use? E.g. for PdfLaTeX it may be necessary to
>> add \usepackage{cmap} immediately after \documentclass. Unicode engines
>> like LuaTeX likely do not require such trick.
> 
> I am wondering if having cmap should be a good default in general.
> Not just for accessibility.

For me it must have, but I am a rare person on this mail list who is 
happy with the Computer Modern font (actually cm-super Type 1 font). I 
have never tried .ttf fonts with PdfLaTeX and I am unaware of effect of 
\usepackage{cmap} in that case.

Re: org exported pdf files

[Max Nikulin]

On 28/09/2022 13:48, Jude DaShiell wrote:
> I don't make pdf files or make pdf files available for
> anyone else.

Then what is the origin of "these" PDF files you mentioned in your first 
post?

If you actually use pdftotext, I am unsure concerning effect of setting 
language for you.

 > Adobe has plenty of pdf accessibility guidelines available for those
 > interested in accessibility to implement.

In general my experience is that plenty of guidelines actually means 
that most of them are already obsolete or describe intentions that have 
never been implemented. So someone should provide more precise technical 
details and links to documents describing currently used techniques. 
Just links provided by a search engine may be hardly relevant to real 
experience of users of assistive technologies.

Re: org exported pdf files

[Tim Cross]

Timothy <orgmode@tec.tecosaur.net> writes:

> Hi Tim,
>
>> It would probably be good to add the two above packages as part of the
>> ’default’ package preamble, but this would require considerable testing
>> as it isn’t known if there will be adverse effects when mixed with other
>> packages.
>
> Those packages are early accessibility experiments, and are /not/ intended for
> wider use. See the top of the <https://github.com/AndyClifton/accessibility>
> README: “Prototype. Not suitable for production”.  The author themselves said in
> a [2020 tex.SE answer] that:
>
>       `accessibility' was developed and published back in 2007 as a proof of concept for
>       some of the KOMA document styles. I got hold of the files from the author in
>       2019 and took over maintenance with her permission. I tidied up the package
>       enough to get it to CTAN, but didn’t update the functionality. I also published
>       it to GitHub to get some feedback on it.
>
>       It seems to have worked well in 2007 for a few test cases. Unfortunately it now
>       fails every test case, and it looks like needing some serious efforts to fix.
>
>       Because of this I no longer think that accessibility is fit for purpose.
>
> They also go on to make a comment I’ve seen a few times from the people working
> on the latex3 accessibility project — basically that in order to actually get
> a /good/ solution, we’ll need to wait till support is baked into the LaTeX core.
>
> If we’re desperate to add this, we’ll likely want to look at `tagpdf' which is
> written by someone working on the latex3 accessibility project. It is apparently
> capable of passing PCA3, however according to the author:
>
>       `tagpdf' hasn’t been written as a user package but to allow experiments and tests
>       and to help to identify missing interfaces in the kernel and in packages. It can
>       change at any time in incompatible ways and it requires some skills to use it.
>
> So, while it may be a particularly boring answer, I think “wait and see” is our
> current best bet.
>
> All the best,
> Timothy
>
>
> [2020 tex.SE answer] <https://tex.stackexchange.com/a/551287/167605>

None of what yuo wrote is a surprise. Unfortunately, it does mean two
things

1. Org mode cannot be used to create accessible PDF documents as long as
it depends on the latex environment to generate those documents. 

2. Technically, Org mode cannot be used in any organisation (specifically government
funded) where ther are policies which require that documents be
accessible. For example, technically, this means we cannot use org mode
in Australian government organisations, which would also include
Universities. I suspect other countries have similar accessibility
requriements, especially in government and government funded
organisations). 

I say technically because despite such policies, the level of
accessibility in many work and educational environments is very poor. In
Australia, few government departments have reached the accessibility
levels specified in policies which are now nearly 20 years old. The
private sector is even worse. While I have seen improvements in the last
40 years, I have yet to work in an environment where just a majority of
the systems I need to access in order to do my job effectively meet
minimal accessibility standards. 

I don't know if other document processors, like perhaps pandoc, can
create PDF files which contain the tagging and other structural
metadatra necessary to make PDFs accessible.

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.

An unfortunate situation really - especially given Emacs has one of the
most powerful and advanced accessibility options available via
emacspeak.

I also won't hold my breath for a new latgex core. THe latex3 initiative
seems to have failed or at least appears to be slower to be realised than perl6! 

Re: org exported pdf files

[Timothy]

[-- Attachment #1: Type: text/plain, Size: 1817 bytes --]

Hi Tim,

> None of what yuo wrote is a surprise. Unfortunately, it does mean two
> things
>
> 1. Org mode cannot be used to create accessible PDF documents as long as
> it depends on the latex environment to generate those documents.

It means that Org mode cannot /currently/ be used…

I have hope that in 1-2y this will change.

> 2. Technically, Org mode cannot be used in any organisation (specifically government

Can’t comment on this.

> I don’t know if other document processors, like perhaps pandoc, can
> create PDF files which contain the tagging and other structural
> metadatra necessary to make PDFs accessible.

Pandoc’s PDFs via LaTeX will have exactly the same problem.

> 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.

HTML has more inherent structure, so this situation is already much better.

> An unfortunate situation really - especially given Emacs has one of the
> most powerful and advanced accessibility options available via
> emacspeak.

Well, Emacs is a bit divorced from this problem.

> I also won’t hold my breath for a new latgex core. THe latex3 initiative
> seems to have failed or at least appears to be slower to be realised than perl6!

Hmm? LaTeX3 switched gear, and arguably is working nicely. I expect you’re
currently using quite a few bits of LaTeX3, even if you don’t know it.

The accessibility effort was started ~2y ago, seems to be making progress
(stalled a bit with covid), and is funded with a roadmap. I see good reason to
think the current situation will change.

All the best,
Timothy

Re: org exported pdf files

[Juan Manuel Macías]

Hi, Tim

Tim Cross writes:

> An unfortunate situation really - especially given Emacs has one of the
> most powerful and advanced accessibility options available via
> emacspeak.
>
> I also won't hold my breath for a new latgex core. THe latex3 initiative
> seems to have failed or at least appears to be slower to be realised than perl6! 

You may find this article by Frank Mittelbach from 2020 interesting,
about the future of LaTeX and the challenges to be solved, including the
accessibility issues:

https://www.latex-project.org/publications/2020-FMi-TUB-tb128mitt-quovadis.pdf

On the other hand, there is also ConTeXt. I don't know much about
ConTeXt, but I remember reading somewhere that ConTeXt is more mature
than LaTeX on PDF tagging and accessibility issues. I don't know if
there are any ConTeXt experts on the list who can confirm this... In any
case, an ox-context already exists for org, written by Jason Ross.

Best regards,

Juan Manuel 

-- 
--
------------------------------------------------------
Juan Manuel Macías 

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

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

[Ihor Radchenko]

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.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Add \usepackage{cmap} as default LaTeX class in ox-latex (was: org exported pdf files)

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> On 28/09/2022 10:07, Ihor Radchenko wrote:
>> Max Nikulin writes:
>> 
>>> - What TeX engine do you use? E.g. for PdfLaTeX it may be necessary to
>>> add \usepackage{cmap} immediately after \documentclass. Unicode engines
>>> like LuaTeX likely do not require such trick.
>> 
>> I am wondering if having cmap should be a good default in general.
>> Not just for accessibility.
>
> For me it must have, but I am a rare person on this mail list who is 
> happy with the Computer Modern font (actually cm-super Type 1 font). I 
> have never tried .ttf fonts with PdfLaTeX and I am unaware of effect of 
> \usepackage{cmap} in that case.

May others familiar with LaTeX comment on this?
If it is safe to add cmap to default LaTeX template, I see no reason why
we should not.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: org exported pdf files

[Max Nikulin]

On 29/09/2022 00:08, Tim Cross wrote:
> 
> 1. Org mode cannot be used to create accessible PDF documents as long as
> it depends on the latex environment to generate those documents.

Are there free tools that can generate accessible PDF documents? 
Perhaps, when it is mandatory requirement, export through HTML or 
through ODT may be a workaround till reasonable support will be 
implemented in LaTeX. I have no idea concerning quality of PDF documents 
generated by e.g. browsers.

Are there free tools that allows to inspect PDF files structure similar 
to DOM inspector from browser development tools? Otherwise it is 
inconvenient to check effects of code modification or to compare result 
with sample files formatted accordingly to guidelines.

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. 

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

[Jude DaShiell]

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.
>
>

Re: Add \usepackage{cmap} as default LaTeX class in ox-latex (was: org exported pdf files)

[Max Nikulin]

On 29/09/2022 11:12, Ihor Radchenko wrote:
> Max Nikulin writes:
> 
>> On 28/09/2022 10:07, Ihor Radchenko wrote:
>>> Max Nikulin writes:
>>>
>>>> - What TeX engine do you use? E.g. for PdfLaTeX it may be necessary to
>>>> add \usepackage{cmap} immediately after \documentclass. Unicode engines
>>>> like LuaTeX likely do not require such trick.
>>>
>>> I am wondering if having cmap should be a good default in general.
>>> Not just for accessibility.
>>
>> For me it must have, but I am a rare person on this mail list who is
>> happy with the Computer Modern font (actually cm-super Type 1 font). I
>> have never tried .ttf fonts with PdfLaTeX and I am unaware of effect of
>> \usepackage{cmap} in that case.
> 
> May others familiar with LaTeX comment on this?
> If it is safe to add cmap to default LaTeX template, I see no reason why
> we should not.

It seems something changed during last decade. I have not tried default 
Type3 raster fonts (I do not remember if it is possible to disable 
cm-super without uninstalling it), but at least with cm-super installed, 
the cmap package is not necessary to have Cyrillic text properly encoded 
in PDF files, not to mention ASCII. I have tried utf8 and cp1251 options 
of inputenc.

However with cmap more math characters get correct unicode symbols

\[ \forall \delta \exists \epsilon \ne t \]

I tried to search for problems that may cause cmap. There is no 
incompatibility with \usepackage[pdfa=true]{hyperref} anymore
https://tex.stackexchange.com/questions/64585/incompatibilities-of-cmap-with-fontenc-hyperref
(side note: the answer marked as accepted is incorrect). So I hope, it 
is safe to use this package for PdfLaTeX.

I have noticed mmap package intended to improve math representation
https://tex.stackexchange.com/questions/64409/proper-use-of-cmap-and-mmap
With the dumb example provided above I have not noticed difference 
between cmap and \usepackage[noTeX]{mmap}. I am unsure when TeX commands 
may be preferred to Unicode characters as it works for default mmap 
configuration.

There is a chance that mmap is not installed in the system since it is 
provided by "extra" system package in Ubuntu:
texlive-latex-recommended: 
/usr/share/texlive/texmf-dist/tex/latex/cmap/cmap.sty
texlive-latex-extra: /usr/share/texlive/texmf-dist/tex/latex/mmap/mmap.sty
It should be possible to detect availability of mmap.sty in runtime 
using kpsewhich command.

So when I was writing that cmap is must have for me, I was not aware 
that nowadays PDF files generated from LaTeX source have mostly properly 
encoded text even without this package, in the past attempt to copy text 
resulted in some garbage.

Re: org exported pdf files

[Tim Cross]

Juan Manuel Macías <maciaschain@posteo.net> writes:

> Hi, Tim
>
> Tim Cross writes:
>
>> An unfortunate situation really - especially given Emacs has one of the
>> most powerful and advanced accessibility options available via
>> emacspeak.
>>
>> I also won't hold my breath for a new latgex core. THe latex3 initiative
>> seems to have failed or at least appears to be slower to be realised than perl6! 
>
> You may find this article by Frank Mittelbach from 2020 interesting,
> about the future of LaTeX and the challenges to be solved, including the
> accessibility issues:
>
> https://www.latex-project.org/publications/2020-FMi-TUB-tb128mitt-quovadis.pdf
>
> On the other hand, there is also ConTeXt. I don't know much about
> ConTeXt, but I remember reading somewhere that ConTeXt is more mature
> than LaTeX on PDF tagging and accessibility issues. I don't know if
> there are any ConTeXt experts on the list who can confirm this... In any
> case, an ox-context already exists for org, written by Jason Ross.
>
> Best regards,
>
> Juan Manuel 
>
> -- 

Thanks Juan, that is a useful link. 

Re: org exported pdf files

[Tim Cross]

Max Nikulin <manikulin@gmail.com> writes:

> On 29/09/2022 00:08, Tim Cross wrote:
>> 1. Org mode cannot be used to create accessible PDF documents as long as
>> it depends on the latex environment to generate those documents.
>
> Are there free tools that can generate accessible PDF documents? Perhaps, when it is
> mandatory requirement, export through HTML or through ODT may be a workaround till
> reasonable support will be implemented in LaTeX. I have no idea concerning quality of PDF
> documents generated by e.g. browsers.
>

There are tools which are free in the sense of free beer, but no tools
I'm aware of which are free in the sense of freedom. The company which
has probably done the most to make PDF files accessible is Adobe and
they do provide a lot of good documentation and some pretty reasonable
tools which can help with diagnosis etc. Unfortunately, their position
wrt software liberty is poor. 

> Are there free tools that allows to inspect PDF files structure similar to DOM inspector
> from browser development tools? Otherwise it is inconvenient to check effects of code
> modification or to compare result with sample files formatted accordingly to guidelines.

Similar to above, but none which are free in the libre sense that I'm
aware of.

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

[Tim Cross]

Dear all,

I think I owe everyone an apology. I have allowed frustration from
another area of life colour my response here and as a result, my tone
and assessment was too negative.

While it is correct that we cannot use org mode to generate accessible
PDFs and that does mean in environments where policy mandates accessible
content (which is PDF), we cannot use org mode.

The ability to generate accessible HTML is on the other hand quite
possible. Unlike PDF, the burden for doing this rests primarily with the
author and not the data processing framework. There are probably some
things we can do to improve or encourage accessible authoring, such as
alerting authors to content which looks like it should have an alt
tag. I will give some thought to that and when I get a chance, will see
how well various html based back ends deal with accessibility checking
tools.

For those interested and because it might help with understanding in
this area, I thought I'd outline the actual cause of my frustration. The
following isn't directly related to org-mode, but may be informative for
some. However, it is a little long, so feel free to just delete and move
on if your so inclined.

There is a little irony here as well. I've been using org mode since it
was first released. I even recall email discussions with Carsten when he
was first looking at how to improve outlining. It is org mode which
allowed me to generate really good quality documents and track all the
data and tasks I had to manage in my various job roles. People often
commented that they found it interesting that some of the best looking
documents produced in our area were from the person who is legally
blind! The irony being I cannot easily access the PDF output I created
and I became part of the problem by generating inaccessible documentation!

One very long standing frustration I have had in my career has been to
do with access to training materials. Most training organisations are
extremely reluctant to provide electronic copies of their learning
materials. I have lost count of the number of non-disclosure forms I
have been forced to sign in order to get electronic documents from a
training organisation (even though they are legally required to provide
their materials in an accessible format). Even when I have managed to
sign the necessary paperwork and get the documents, they have often been
in the form of DRM protected PDFs with an expiration date. While those
without any disability can retain the learning materials for future
reference, it is not a luxury afforded to anyone dependent on assistive
technology. Worse yet, most DRM protected formats also require the use
of non-free platforms, such as Windows or MacOS (I did often get some
perverse satisfaction from cracking the DRM protection, which in most
cases, is fairly easy to do). However, there is an ironic component here
as well. Usually, the DRM protected PDFs are actually very accessible
once you jump through all the necessary hoops. They are typically well
tagged and easy to navigate. On the other hand, the non-DRM PDFs are
rarely accessible despite correctly formatted PDFs actually being one of
the most accessible formats available. Often, once forced to provide
electronic copies of their learning materials, training organisations
will provide image PDFs, generated from a scanned version of their
materials. Image PDFs are 100% inaccessible - they are just pictures, so
you cannot even extract the text using tools like pdftotext[1] Even when
not image PDFs, they often lack the necessary tagging etc (though, this
situation has improved in recent years as many tools now default to
accessible output rather than requiring it to be enabled).

Even once you jump through all the necessary hoops, your not out of the
woods yet. My current frustration has been with obtaining the important
bit of paper which says your trained and certified. After completing the
course I looked at what I needed to do to sit the certification
exam. The exam is one which has to be done at a large certification
examination centre and it is done electronically. It is actually run by
a very large US based training organisation, who I will not name.

It runs out that I cannot do the training at this time. I have to give
them  a minimum of 12 months notice to sit the certification exam
because due to my 'special' needs, the whole examination centre has to
be booked out just for me! To make it worse, the assistive technology I
have to use is a program called JAWS, which only runs on windows and
which I am totally unfamiliar with. My suggestion to just have a
sighted person assist me by reading the questions and entering the
answers has been rejected as well as all other suggestions and
appeals. It is highly likely I will just forgo certification. While it
would have been handy, it isn't essential.

I outline all of this not for sympathy but to try and promote
understanding of the challenges faced by many who need access to
accessible content. Accessibility is also an area which isn't well
serviced by the open source community. This is not a criticism, just an
observation. It is also easy to understand why. Most successful open
source projects are about scratching an itch. Org mode was born by one
person (Carsten) scratching an itch which turned out to be an itch many
others also had. With accessibility, the number of people wit the itch
is significantly smaller and there is a lot of itch variation. Those
with the technical skill to scratch it are even smaller. 

regards,

Tim

[1] I have had some people say to me that the situation isn't that bad
with PDFs as you can use tools like pdftotext to extract the text from
the files and then read it with a screen reader. Unfortunately, this
approach does not always provide good output. Often, the structure of
the document is lost and bits become tangled/jumbled (consider what is
the best way to dump text from a table in a linear manner when you have
little meta data about that table. The output also often contains
'artifacts' and odd characters as well as spurious spaces which make it
difficult to understand or process correctly by the text-to-speech
system. 

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

[tomas]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

On Fri, Sep 30, 2022 at 07:05:40AM +1000, Tim Cross wrote:
> 
> Dear all,
> 
> I think I owe everyone an apology [...]

> For those interested and because it might help with understanding in
> this area, I thought I'd outline the actual cause of my frustration [...]

No, I for one are grateful for the chance to understand your
perspective. Lacking your experience, I'm dependent on the
likes of you to get an idea on perspectives I've no experience
with.

So thanks!

Cheers
-- 
tomás 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: org exported pdf files

[Max Nikulin]

On 29/09/2022 00:08, Tim Cross wrote:
> 
> 2. Technically, Org mode cannot be used in any organisation (specifically government
> funded) where ther are policies which require that documents be
> accessible. For example, technically, this means we cannot use org mode
> in Australian government organisations, which would also include
> Universities. I suspect other countries have similar accessibility
> requriements, especially in government and government funded
> organisations).

Can someone having experience with assistive technologies comment if 
output generated by ox-html prevents generation of accessible PDF by 
Chrome? Are serious rework is required to improve HTML export? Let's 
leave math expressions aside for a while.

https://blog.chromium.org/2020/07/using-chrome-to-generate-more.html
Dominic Mazzoni. Using Chrome to generate more accessible PDFs
Wednesday, July 29, 2020

More tools promise PDF/UA generation from HTML, e.g.
https://github.com/Kozea/WeasyPrint/issues/1088
liZe commented Sep 16, 2022
> 
> Version 57 will include PDF/UA support that includes accessibility
> tags automatically added out of the HTML structure of the document. If
> anyone is interested in this feature, don’t hesitate to test the current
> master branch and add a comment here!

Certainly there is enough room for improvements of ox-html and there 
were discussions of "slim" HTML ox backend. Such work may include 
suggestions from people familiar with ARIA and related web technologies.

[HELP] Help implementing org-lint/warnings buffer during export (was: Org HTML export accessibility (was: org exported pdf files))

[Ihor Radchenko]

Tim Cross <theophilusx@gmail.com> writes:

> 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.

This sounds like a good idea.

Org currently attempts to be slightly helpful by indicating, for
example, LaTeX compilation warnings. However, it is just done by writing
a simple message in the echo area.

What would be more useful is the kind of buffer displayed by org-lint,
but instead used during export:
- If there are any export issues (LaTeX errors/warnings) they can appear
  in the buffer
- If there are any stylistic issues (like lack of alt attributes during
  html export), they can also appear

Ideally, we should be able to jump directly to the line containing
error.

org-lint code could be used as a base, but otherwise we need to
implement something generic way to check style/export warnings on
per-backend basis.

This is probably something we need to do before we dive into the
accessibility specifics. AFAIU from the Tim's reply, many of the
accessibility guidelines may need to be decided by the document author.
Tim, let me know if I am wrong and some of the accessible tagging must
be done unconditionally.

I am marking this as a help request.

Let me know what you think.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: Apology [

[Fraga, Eric]

Dear Tim,

thank you very much for the long email.  It is very helpful, at least
for me, to have a much better understanding of accessibility issues.

And, by the way, I did not think you had been overly negative and
definitely no apology was required.

take care,
eric

-- 
: Eric S Fraga, with org release_9.5.5-851-ge9781f in Emacs 29.0.50

Re: [HELP] Help implementing org-lint/warnings buffer during export (was: Org HTML export accessibility (was: org exported pdf files))

[Tim Cross]

Ihor Radchenko <yantar92@gmail.com> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> 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.
>
> This sounds like a good idea.
>
> Org currently attempts to be slightly helpful by indicating, for
> example, LaTeX compilation warnings. However, it is just done by writing
> a simple message in the echo area.
>
> What would be more useful is the kind of buffer displayed by org-lint,
> but instead used during export:
> - If there are any export issues (LaTeX errors/warnings) they can appear
>   in the buffer
> - If there are any stylistic issues (like lack of alt attributes during
>   html export), they can also appear
>
> Ideally, we should be able to jump directly to the line containing
> error.
>
> org-lint code could be used as a base, but otherwise we need to
> implement something generic way to check style/export warnings on
> per-backend basis.
>
> This is probably something we need to do before we dive into the
> accessibility specifics. AFAIU from the Tim's reply, many of the
> accessibility guidelines may need to be decided by the document author.
> Tim, let me know if I am wrong and some of the accessible tagging must
> be done unconditionally.
>
> I am marking this as a help request.
>
> Let me know what you think.

I had a very similar idea wrt lint like functionality to alert user to
possible 'stylistic' and/or other problems in exported content. Adding
accessibility to that would then be the next step.

I'm very much against enforcing standards. Experience has taught me that
these sorts of thing change more frequently then you might expect. Also,
like the old sayings go "every rule has an exception" "you need to know
the rules before you can break them", etc. Far better to provide the
tools which can assist the author, but avoid enforcing some particular
view/opinion.

We would probably want to make the linting rules dynamic - allowing easy
add/removal/update of rules. People could then possibly use it to also
check for local policy/standard requirements by adding their own. 

Re: [HELP] Help implementing org-lint/warnings buffer during export (was: Org HTML export accessibility (was: org exported pdf files))

[Ihor Radchenko]

Tim Cross <theophilusx@gmail.com> writes:

> I had a very similar idea wrt lint like functionality to alert user to
> possible 'stylistic' and/or other problems in exported content. Adding
> accessibility to that would then be the next step.
>
> I'm very much against enforcing standards. Experience has taught me that
> these sorts of thing change more frequently then you might expect. Also,
> like the old sayings go "every rule has an exception" "you need to know
> the rules before you can break them", etc. Far better to provide the
> tools which can assist the author, but avoid enforcing some particular
> view/opinion.
>
> We would probably want to make the linting rules dynamic - allowing easy
> add/removal/update of rules. People could then possibly use it to also
> check for local policy/standard requirements by adding their own. 

Agree. Note that we do have `org-lint-add-checker'.
Disabling/suppressing checks is also a good thing to add.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>