* org exported pdf files @ 2022-09-27 1:48 Jude DaShiell 2022-09-27 2:48 ` Ihor Radchenko 0 siblings, 1 reply; 34+ messages in thread From: Jude DaShiell @ 2022-09-27 1:48 UTC (permalink / raw) To: emacs-orgmode 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) . ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: org exported pdf files 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 0 siblings, 1 reply; 34+ messages in thread From: Ihor Radchenko @ 2022-09-27 2:48 UTC (permalink / raw) To: Jude DaShiell; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: org exported pdf files 2022-09-27 2:48 ` Ihor Radchenko @ 2022-09-27 3:15 ` Jude DaShiell 2022-09-27 3:24 ` Ihor Radchenko 0 siblings, 1 reply; 34+ messages in thread From: Jude DaShiell @ 2022-09-27 3:15 UTC (permalink / raw) To: Ihor Radchenko; +Cc: emacs-orgmode 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? > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: org exported pdf files 2022-09-27 3:15 ` Jude DaShiell @ 2022-09-27 3:24 ` Ihor Radchenko 2022-09-27 4:31 ` Jude DaShiell 0 siblings, 1 reply; 34+ messages in thread From: Ihor Radchenko @ 2022-09-27 3:24 UTC (permalink / raw) To: Jude DaShiell; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: org exported pdf files 2022-09-27 3:24 ` Ihor Radchenko @ 2022-09-27 4:31 ` Jude DaShiell 2022-09-27 4:58 ` Ihor Radchenko 2022-09-27 11:08 ` Max Nikulin 0 siblings, 2 replies; 34+ messages in thread From: Jude DaShiell @ 2022-09-27 4:31 UTC (permalink / raw) To: Ihor Radchenko; +Cc: emacs-orgmode 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. > > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: org exported pdf files 2022-09-27 4:31 ` Jude DaShiell @ 2022-09-27 4:58 ` Ihor Radchenko 2022-09-28 4:36 ` Jude DaShiell 2022-09-27 11:08 ` Max Nikulin 1 sibling, 1 reply; 34+ messages in thread From: Ihor Radchenko @ 2022-09-27 4:58 UTC (permalink / raw) To: Jude DaShiell; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: org exported pdf files 2022-09-27 4:58 ` Ihor Radchenko @ 2022-09-28 4:36 ` Jude DaShiell 2022-09-28 4:53 ` Timothy 0 siblings, 1 reply; 34+ messages in thread From: Jude DaShiell @ 2022-09-28 4:36 UTC (permalink / raw) To: Ihor Radchenko; +Cc: emacs-orgmode 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/ > > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: org exported pdf files 2022-09-28 4:36 ` Jude DaShiell @ 2022-09-28 4:53 ` Timothy 2022-09-28 6:48 ` Jude DaShiell 0 siblings, 1 reply; 34+ messages in thread From: Timothy @ 2022-09-28 4:53 UTC (permalink / raw) To: emacs-orgmode; +Cc: Ihor Radchenko, emacs-orgmode [-- 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: org exported pdf files 2022-09-28 4:53 ` Timothy @ 2022-09-28 6:48 ` Jude DaShiell 2022-09-28 8:47 ` Tim Cross 2022-09-28 16:12 ` Max Nikulin 0 siblings, 2 replies; 34+ messages in thread From: Jude DaShiell @ 2022-09-28 6:48 UTC (permalink / raw) To: Timothy, emacs-orgmode; +Cc: Ihor Radchenko 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 > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: org exported pdf files 2022-09-28 6:48 ` Jude DaShiell @ 2022-09-28 8:47 ` Tim Cross 2022-09-28 9:19 ` Timothy 2022-09-28 13:02 ` Jude DaShiell 2022-09-28 16:12 ` Max Nikulin 1 sibling, 2 replies; 34+ messages in thread From: Tim Cross @ 2022-09-28 8:47 UTC (permalink / raw) To: Jude DaShiell; +Cc: Timothy, Ihor Radchenko, emacs-orgmode 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: org exported pdf files 2022-09-28 8:47 ` Tim Cross @ 2022-09-28 9:19 ` Timothy 2022-09-28 17:08 ` Tim Cross 2022-09-28 13:02 ` Jude DaShiell 1 sibling, 1 reply; 34+ messages in thread From: Timothy @ 2022-09-28 9:19 UTC (permalink / raw) To: emacs-orgmode; +Cc: Jude DaShiell, Timothy, Ihor Radchenko, emacs-orgmode [-- 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> ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: org exported pdf files 2022-09-28 9:19 ` Timothy @ 2022-09-28 17:08 ` Tim Cross 2022-09-28 17:39 ` Timothy ` (4 more replies) 0 siblings, 5 replies; 34+ messages in thread From: Tim Cross @ 2022-09-28 17:08 UTC (permalink / raw) To: Timothy; +Cc: Jude DaShiell, Ihor Radchenko, emacs-orgmode 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! ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: org exported pdf files 2022-09-28 17:08 ` Tim Cross @ 2022-09-28 17:39 ` Timothy 2022-09-28 18:23 ` Juan Manuel Macías ` (3 subsequent siblings) 4 siblings, 0 replies; 34+ messages in thread From: Timothy @ 2022-09-28 17:39 UTC (permalink / raw) To: emacs-orgmode; +Cc: Timothy, Jude DaShiell, Ihor Radchenko, emacs-orgmode [-- 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: org exported pdf files 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 ` (2 subsequent siblings) 4 siblings, 1 reply; 34+ messages in thread From: Juan Manuel Macías @ 2022-09-28 18:23 UTC (permalink / raw) To: Tim Cross; +Cc: Timothy, Jude DaShiell, Ihor Radchenko, emacs-orgmode 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: org exported pdf files 2022-09-28 18:23 ` Juan Manuel Macías @ 2022-09-29 20:58 ` Tim Cross 0 siblings, 0 replies; 34+ messages in thread From: Tim Cross @ 2022-09-29 20:58 UTC (permalink / raw) To: Juan Manuel Macías Cc: Timothy, Jude DaShiell, Ihor Radchenko, emacs-orgmode 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Org HTML export accessibility (was: org exported pdf files) 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 4:09 ` Ihor Radchenko 2022-09-29 8:22 ` Tim Cross 2022-09-29 7:07 ` org exported pdf files Max Nikulin 2022-10-01 10:55 ` Max Nikulin 4 siblings, 1 reply; 34+ messages in thread From: Ihor Radchenko @ 2022-09-29 4:09 UTC (permalink / raw) To: Tim Cross; +Cc: Timothy, Jude DaShiell, emacs-orgmode 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Org HTML export accessibility (was: org exported pdf files) 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 ` (2 more replies) 0 siblings, 3 replies; 34+ messages in thread From: Tim Cross @ 2022-09-29 8:22 UTC (permalink / raw) To: Ihor Radchenko; +Cc: Timothy, Jude DaShiell, emacs-orgmode 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Org HTML export accessibility (was: org exported pdf files) 2022-09-29 8:22 ` Tim Cross @ 2022-09-29 11:43 ` Jude DaShiell 2022-09-29 21:05 ` Apology [was: Re: Org HTML export accessibility (was: org exported pdf files)) Tim Cross 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 2 siblings, 0 replies; 34+ messages in thread From: Jude DaShiell @ 2022-09-29 11:43 UTC (permalink / raw) To: Tim Cross, Ihor Radchenko; +Cc: Timothy, emacs-orgmode 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. > > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Apology [was: Re: Org HTML export accessibility (was: org exported pdf files)) 2022-09-29 8:22 ` Tim Cross 2022-09-29 11:43 ` Jude DaShiell @ 2022-09-29 21:05 ` 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 2 siblings, 2 replies; 34+ messages in thread From: Tim Cross @ 2022-09-29 21:05 UTC (permalink / raw) To: Ihor Radchenko; +Cc: Timothy, Jude DaShiell, emacs-orgmode 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Apology [was: Re: Org HTML export accessibility (was: org exported pdf files)) 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 1 sibling, 0 replies; 34+ messages in thread From: tomas @ 2022-09-30 5:34 UTC (permalink / raw) To: emacs-orgmode [-- 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 --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Apology [ 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 ` Fraga, Eric 1 sibling, 0 replies; 34+ messages in thread From: Fraga, Eric @ 2022-10-02 10:59 UTC (permalink / raw) To: Tim Cross; +Cc: emacs-orgmode@gnu.org 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* [HELP] Help implementing org-lint/warnings buffer during export (was: Org HTML export accessibility (was: org exported pdf files)) 2022-09-29 8:22 ` Tim Cross 2022-09-29 11:43 ` Jude DaShiell 2022-09-29 21:05 ` Apology [was: Re: Org HTML export accessibility (was: org exported pdf files)) Tim Cross @ 2022-10-02 9:42 ` Ihor Radchenko 2022-10-02 20:52 ` Tim Cross 2 siblings, 1 reply; 34+ messages in thread From: Ihor Radchenko @ 2022-10-02 9:42 UTC (permalink / raw) To: Tim Cross; +Cc: Timothy, Jude DaShiell, emacs-orgmode 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [HELP] Help implementing org-lint/warnings buffer during export (was: Org HTML export accessibility (was: org exported pdf files)) 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 0 siblings, 1 reply; 34+ messages in thread From: Tim Cross @ 2022-10-02 20:52 UTC (permalink / raw) To: Ihor Radchenko; +Cc: Timothy, Jude DaShiell, emacs-orgmode 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [HELP] Help implementing org-lint/warnings buffer during export (was: Org HTML export accessibility (was: org exported pdf files)) 2022-10-02 20:52 ` Tim Cross @ 2022-10-03 3:25 ` Ihor Radchenko 0 siblings, 0 replies; 34+ messages in thread From: Ihor Radchenko @ 2022-10-03 3:25 UTC (permalink / raw) To: Tim Cross; +Cc: Timothy, Jude DaShiell, emacs-orgmode 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> ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: org exported pdf files 2022-09-28 17:08 ` Tim Cross ` (2 preceding siblings ...) 2022-09-29 4:09 ` Org HTML export accessibility (was: org exported pdf files) Ihor Radchenko @ 2022-09-29 7:07 ` Max Nikulin 2022-09-29 21:00 ` Tim Cross 2022-10-01 10:55 ` Max Nikulin 4 siblings, 1 reply; 34+ messages in thread From: Max Nikulin @ 2022-09-29 7:07 UTC (permalink / raw) To: emacs-orgmode 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: org exported pdf files 2022-09-29 7:07 ` org exported pdf files Max Nikulin @ 2022-09-29 21:00 ` Tim Cross 0 siblings, 0 replies; 34+ messages in thread From: Tim Cross @ 2022-09-29 21:00 UTC (permalink / raw) To: Max Nikulin; +Cc: emacs-orgmode 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: org exported pdf files 2022-09-28 17:08 ` Tim Cross ` (3 preceding siblings ...) 2022-09-29 7:07 ` org exported pdf files Max Nikulin @ 2022-10-01 10:55 ` Max Nikulin 4 siblings, 0 replies; 34+ messages in thread From: Max Nikulin @ 2022-10-01 10:55 UTC (permalink / raw) To: emacs-orgmode 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: org exported pdf files 2022-09-28 8:47 ` Tim Cross 2022-09-28 9:19 ` Timothy @ 2022-09-28 13:02 ` Jude DaShiell 1 sibling, 0 replies; 34+ messages in thread From: Jude DaShiell @ 2022-09-28 13:02 UTC (permalink / raw) To: Tim Cross; +Cc: Timothy, Ihor Radchenko, emacs-orgmode 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. > > > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: org exported pdf files 2022-09-28 6:48 ` Jude DaShiell 2022-09-28 8:47 ` Tim Cross @ 2022-09-28 16:12 ` Max Nikulin 1 sibling, 0 replies; 34+ messages in thread From: Max Nikulin @ 2022-09-28 16:12 UTC (permalink / raw) To: Jude DaShiell, emacs-orgmode 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: org exported pdf files 2022-09-27 4:31 ` Jude DaShiell 2022-09-27 4:58 ` Ihor Radchenko @ 2022-09-27 11:08 ` Max Nikulin 2022-09-28 3:07 ` Ihor Radchenko 1 sibling, 1 reply; 34+ messages in thread From: Max Nikulin @ 2022-09-27 11:08 UTC (permalink / raw) To: emacs-orgmode; +Cc: Jude DaShiell 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: org exported pdf files 2022-09-27 11:08 ` Max Nikulin @ 2022-09-28 3:07 ` Ihor Radchenko 2022-09-28 15:58 ` Max Nikulin 0 siblings, 1 reply; 34+ messages in thread From: Ihor Radchenko @ 2022-09-28 3:07 UTC (permalink / raw) To: Max Nikulin; +Cc: emacs-orgmode, Jude DaShiell 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: org exported pdf files 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 0 siblings, 1 reply; 34+ messages in thread From: Max Nikulin @ 2022-09-28 15:58 UTC (permalink / raw) To: emacs-orgmode 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Add \usepackage{cmap} as default LaTeX class in ox-latex (was: org exported pdf files) 2022-09-28 15:58 ` Max Nikulin @ 2022-09-29 4:12 ` Ihor Radchenko 2022-09-29 15:34 ` Max Nikulin 0 siblings, 1 reply; 34+ messages in thread From: Ihor Radchenko @ 2022-09-29 4:12 UTC (permalink / raw) To: Max Nikulin, Daniel Fleischer; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Add \usepackage{cmap} as default LaTeX class in ox-latex (was: org exported pdf files) 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 0 siblings, 0 replies; 34+ messages in thread From: Max Nikulin @ 2022-09-29 15:34 UTC (permalink / raw) To: emacs-orgmode 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2022-10-03 3:25 UTC | newest]
Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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
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).