Publishing accessible proceedings: the DSAI 2016 case study

Access to research papers has changed in the last decades: from printed to digital sources, from close to open access. Despite these changes and broader access to research results, there are still accessibility barriers. A very small number of conferences and journals state an accessibility policy for the publications in their websites. The production of accessible documents is not a common practice in conferences devoted to accessibility. The purpose of this paper is to present the case study of DSAI 2016 (Software Development and Technologies for Enhancing Accessibility and Fighting Info-exclusion) conference, wherein we were in charge of making accessible its proceedings. We discuss the methods and technical procedures we carried out to turn the original articles in MS Word and LaTEX formats into accessible PDFs and the steps necessary in authoring, conversion and validation. The papers of DSAI 2016 were published in accessible format after much effort; best tools and procedure were using MS Word plus PDF Axes plus PDF Accessibility checker. We state the need to include a new role in the organizing committee of conferences for dealing with accessible publishing.


Introduction
Academic conferences should be accessible by default [1,2]. Otherwise, the dissemination of scientific knowledge for all is seriously hindered. In this paper, we concentrate on the technical accessibility of conference proceedings. By accessibility we do not mean free access to conference proceedings. Accessibility, in this paper, means being able to read the papers published in the conference proceedings regardless of any disability or impairment one might have, or software one might use. In addition to being the main scientific output of a conference, the proceedings are often part of the bibliography for higher education courses, and a basic source of information for researchers. Thus, publishing in accessible formats is of utmost importance, and a matter of respect, compromise and coherence, especially for those conferences dealing with accessibility and digital technologies. Several conferences have promoted initiatives to foster the publication of accessible proceedings. TEX users group (TUG) has also been active working on this issue. However, the results are still not consolidated, and articles are not accessible [3].
In this paper, we reflect on our own experience of publishing the proceedings of the 7th International Conference on Software Development and Technologies for Enhancing Accessibility and Fighting Info-exclusion (DSAI 2016) in an accessible format. We share what we learned about the possibilities and limitations of authoring tools, such as MS Word, InDesign, Acrobat DC and PDF Axes for Word, to create accessible proceedings or convert them into an accessible format. We argue that publishing accessible proceedings is not straightforward and that it requires a lot of planning at the submission stage. We highlight the importance of an effective communication between the authors and the publishing team to speed up the generation of accessible proceedings. We also indicate that LaTEX sources are still not correctly addressed with the current tools and technologies.
Although it is difficult to make general claims from case studies, the lessons learned encourage us to argue that generating accessible conference proceedings in an easy, efficient and effective way is currently a very difficult objective to achieve, and that we need an integrated workflow to make it a more feasible task. Our suggested workflow consists of four key elements: better tools, better communication between conference organizers and researchers, better templates and instructions and increased awareness of accessibility. The paper is organized as follows. In the Background section, we provide an overview of tools, formats and technical procedures. In the Related Research section, we review and discuss previous initiatives related to this paper. We then present the case study, reflect on the lessons learned and the actions taken, and present our proposal. We end up with a discussion, conclusion and future research perspectives.

Background
This section aims to provide a background on accessible publishing. In Sect. 2.1, we give a succinct overview of the main digital formats and tools used to author accessible documents. Afterward, we summarize three key steps in the publishing process: preparation of originals, conversion and validation. Table 2 presents a summary of steps and tools.

Format and tools
The technical format of a digital document establishes a threshold on its accessibility, which is determined by authoring and reading tools [4]. For example, HTML is a very flexible format, because HTML files separate the content from the presentation. The complete source of the file can be seen while authoring it, which gives the authors high control over the final results. In what follows, we review the most common formats in which conference proceedings are usually published: PDF, TeX and MSWord. We also turn our attention to a relatively new file format, namely EPUB3.

Pdf
The main goal of the Portable Document Format (PDF) is to offer presentation reliability through different platforms and printing devices. The company's strategy to offer Adobe Reader freely and to actively listen to the prepress professionals' needs did pay back with a high adoption rate against competing formats such as Dejavu. PDF was a proprietary format until 2008, when, led by the pressure of governments to use open formats, it became an ISO standard. A further step was taken in 2012 when, again caused by legislation requirements' pressures, it incorporated accessibility in its variant PDF/UA [5]. PDF/UA 1 is a new standard coherent with WCAG 2.0 guidelines, and is detailed in ISO 14289-1:2012 (version 1) and ISO 14289-2 (version 2) standards [6]. Following the changes within the format, Adobe Reader has incorporated some worth mentioning accessibility functions, such as the possibility to resize text, reflow the content as a unique column, change colors, automatically play forward or back the pages, and, if the platform provides a screen-reader API feature, to read aloud the content.
The main limitation of PDF lies in its binary format, which is not suitable for a raw authoring procedure such as LaTEX or HTML. There are tools, though, such as Framemaker, which work with XML to create PDF documents. On 2009, Adobe labs released the Mars Project to offer an XML version of the format. However, the project was discontinued and no further steps have been taken at the time of writing this paper. Due to the PDF origins, many authoring tools only focus on the layout and presentation, and do not incorporate either the new semantic structure created since PDF version 1.7 or the new elements introduced in PDF/ UA. Despite these shortcomings, PDF is widely regarded as the most reliable publishing format in every platform. Adobe Reader is a reading tool offering flexibility for creative layouts, different fonts and all kinds of special symbols, with a perfect presentation wherever it is used, except for mobile versions of Adobe Reader which, unfortunately, do not offer reflow capabilities. Adobe released in 2017 a new version of its main standard, Document management-Portable Document format Part 2: PDF 2.0 [5], which is still under development.

Docx
The Open office document format is generated by MS Word, from the Microsoft Office suite. Docx is one of the most widely used formats. Since 2010, MS Word includes an accessibility wizard that automatically checks, among other features, if there is alternative text and if the headings hierarchy is correct. Docx is rarely used as an output format, because the appearance may change depending on the platform or device used. Therefore, it is common to create a PDF document as the final version of an MS Word document. By default, MS Word offers a conversion tool to PDF. Yet, this conversion is not perfect and the final document does not follow PDF specifications. Another way to generate a PDF from a docx document is to add a plugin from Adobe Acrobat in MS Word. Although this plugin helps authors to improve the quality of the resultant PDF, this procedure will not create a compliant PDF/UA document. As already mentioned, there are other tools which are especially geared toward converting from docx to PDF/UA documents, mainly Axes PDF 2 and NetCentric CommonLook. 3

Tex
TEX is a typesetting system designed by Donald Knuth in 1978 in response to two needs: the production of highquality books and the portability of documents, both with free software. TEX is mainly used to create documents with mathematical formulas. TEX consists of plain text with marks to indicate semantics. The output of a TEX document is usually a PDF document. LaTEX is a widely used document writing system. LaTEX aims to simplify TEX document authoring and is free. Since its creation, TEX has not undergone big changes, because backward compatibility is more valued than evolution. This lack of evolution is both its main advantage and disadvantage. This implies, for example, that while it is possible to read a 30-year-old document today, it is impossible to include any videos, audios or activities, such as quizzes. TEX users, who are spread worldwide, have developed and made available numerous libraries to implement specific functions within TEX. Such a large number of libraries might create incompatibility problems. As an example, to avoid incompatibility issues, a specific TEX library to include accessibility requirements was used in CHI 2014 (Computer Human Interaction conference).

Electronic publication format (EPUB)
EPUB was created in 1999 by the International Digital Publishing Forum (IDPF)-named Open eBook forum at that time-to avoid the standard fragmentation in eBook formats. This fragmentation forced publishers to publish their contents in several proprietary formats. In Switzerland, in parallel, a group of researchers worked together to define a format suitable for very different needs, in terms of both presentation and interaction. This work led to the Digital Accessibility Information System (DAISY) format [7]. DAISY aimed to be a format suitable for any type of document. DAISY gained momentum in 2000 [8] but it was not widely adopted, as it was very specific for blind or low-vision people. In 2011, IDPF and DAISY Consortium joined forces and created a new version of the EPUB technical specification, EPUB3. The new version of EPUB brought together the best of both worlds: a rich and flexible format for publishers plus a format adaptable to many different user profiles. The goals were to get maximum adoption and to become the preferred format for small and big publishers, looking toward mainstreaming accessibility.
EPUB3 versatility is making it a suitable format for teaching and learning. In 2011, EPUB 3 gained the endorsement of the publishing industry as the single standard to rely on. Additionally, EPUB3 is the format of choice by the accessible books consortium [9], which is led by the World Intellectual Property Organization (WIPO), including World Blind Union, International Authors Forum, IFLA and International Publishers Association. IDPF's recent merge with W3C is another sign of this trend to become a full standard for the digital world. Yet, there is a lack of authoring and conversion tools. For example, MS Word does not offer a process to convert Docx or doc documents to EPUB. To do so, we have to Save as Daisy, by adding the Add-In Word plugin 4 by the DAISY Consortium. This option generates a DAISY Digital Talking Book (DTB) [10] document, which can be converted to EPUB3 using Tobi 5 desktop tool [11].

Images
The Docx format does not cover vector images, which offer many advantages for zooming and are especially suitable for low-vision users. Docx relies mainly on bitmap images. Bitmap most standardized formats are GIF, PNG and JPEG. JPEG is most similar to PDF internal image format and does not include a transparency layer, avoiding some occlusion problems when customizing colors in Adobe Reader.

Publishing process
Three key steps are involved in publishing accessible conference proceedings, namely the preparation of originals, conversion to the publishing format and validation. The second and third steps can be done by either authors or the organizing committee or an outsourced service.

Preparation of originals
Manuscripts are usually authored in either MS Word or LaTEX, and then converted to PDF. As mentioned above, the PDF generated by LaTEX is not accessible and must be repaired. There are better tools for the conversion from MS Word to PDF, such as Axes PDF and NetCentric CommonLook.
Most accessibility flaws are often due to the template for documents provided to the authors. Examples are tables and images without alternative text, an incorrect hierarchy of titles, and a lack of embedded fonts. The template, which usually gives instructions on how to write papers, does not come with accessibility recommendations. Thus, the original documents do not have metadata, use tables as layout tools, and tend to miss alternative texts for images. All this information is essential for generating accessible documents.
For LaTEX documents, one of the possible solutions to create accessible PDF documents is to use the Infty Editor, a scientific optical text recognition that creates accessible PDF from an image or from a PDF file. We used this editor with real authored articles. The authors found that this tool identifies many textual contents as formulas, making it difficult to process the resulting PDF documents. Another possible solution is to repair the converted PDF with Adobe Acrobat editing capabilities. However, this solution is tedious for complex documents, because the interface for editing tags is not usable. Finally, TEX documents can be repurposed as MS Word documents; in this case, you may find that author templates for MS Word and LaTEX are not the same. Thus, the repurposing is not straightforward; formulas and vector images require specific conversions too, and the conversion may imply some layout changes.
For MS Word documents, if the tool settings are not configured properly, images are downsized to low resolution. Missing information such as alternatives, fonts or metadata is the common problems in generating accessible documents from doc or docx originals.

Conversion
The conversion from MS Word to PDF is not straightforward, even with professional tools such as Adobe ® Acrobat. Adobe ® Acrobat DC is a full editing tool that allows to create a compliant PDF/UA document. Adobe ® Acrobat DC offers complete functionalities to edit and delete the semantic structure of a document. However, the conversion plugin for MS Word does not follow PDF/UA requirements, and to comply with them, one should rely on a post hoc manual editing, which is a tedious process. Authors trying to create PDF/UA documents are overwhelmed with complex and time-consuming repairing tasks on the final documents [12]. For example, the tags created by default in the conversion procedure (see Table 1) are a reduced set of the more heterogeneous possibilities PDF/UA offers to the author.
One very important failure in the conversion process is the missing < document > tag, which is the root element of any PDF document structure.
Another possibility to create PDF documents from MS Word is to use Adobe ® InDesign. Adobe ® InDesign is the main authoring tool for PDF documents. It offers  6 ) and also an InDesign template (see the ACM InDesign counterpart 7 ) with structural tags that have the same names so that the styles will automatically be converted to the corresponding tag. The template can also be populated with a prerecorded list of tags. 8 There are some settings that must be customized in order to create a PDF/ UA document, these can be defined in a joboptions file or in the metadata, where you have to set the author and title (this information is not retrieved from the original Word document) and also the PDF/UA rdf description. 9 The main drawback of the conversion from InDesign to PDF is, again, the reduced number of tags generated. Although the tags keep their names, all the tags except for lists, tables and links, which are automatically recognized and tagged correctly, are repurposed to P, H, H1, H2, H3, H4, H5, H6 internally. If you want to use the original or a more complete tag set, you must post-process the documents (either one by one or by a script) and map the names to the correct tag.
AxesPDF is another tool to convert documents from MS Word to PDF, especially designed with accessibility in mind. The converted files follow the PDF/UA-1 standard. AxesPDF is a tool that takes the author in consideration and streamlines some of the cumbersome steps of the conversion process by, for example, embedding the fonts, including PDF/UA xml metadata, and converting table borders to artifacts. The conversion process can be customized within the tool to establish particular conversion preferences [11]. Although this tool does not cover many tags, apart from the basic ones, it includes Caption, and BlockQuote, which are handy for conferences, because conference proceedings are full of images, and often include scientific quotes.

Validation
Validation is a mandatory step in order to obtain compliant PDF documents. Authoring tools may not follow the required specifications. Validation could be done at any stage of the authoring process. However, given that detecting an error later on in the process might entail carrying out a large number of steps, it is common to validate the generated documents as soon as possible. For example, it is a good practice to do the first validation in the original Word documents. This can be done by using the MS Word accessibility wizard. This first validation can help authors detect, for example, failures in providing alternative texts, in tables and in headings hierarchy.
After the conversion to PDF, a second validation step is necessary. This step consists of following the Matterhorn Protocol, 10 which includes 31 checkpoints and 136 fail conditions. From these 136 conditions, 108 can be automatically validated, while the others require a manual review. The automatic review can be done using the Adobe Acrobat Accessibility validation tool or by specialized tools such as PDF Accessibility Checker. PDF Accessibility Checker version 2.0 (PAC2) is free, promoted by the "Access for All" Swiss foundation, 11 and developed by xyMedia. 12 PDF Accessibility Checker allows to technically validate PDF documents against the PDF/UA Standard. The tool gives aggregated and detailed results of the checkpoints, and offers a detailed view of the document section highlighting errors. It also offers the possibility to view the document with structural tags embedded to evaluate the correct semantics and reading order ( Table 2).

Related research
As stated in [3], the accessibility level of conference proceedings, even those related to accessibility, is not satisfactory and does not comply with current standards. There are numerous barriers, such as access to formulas or missing alternative texts which hinder access to conference proceedings by blind people, people with dyslexia, and people who rely on computers to read aloud or interpret content.
ACM SIGCHI was the first to promote accessibility requirements in their conferences. In CHI 2014, the sigchi-latex Google Code Project 13 was an initiative to create accessible PDFs from LaTEX sources. This initiative was possible thanks to Schalitz, who created an "accessibility" LaTEX package for covering alternate texts for images and table headers. This package allows us to generate tagged PDFs, which indicate the default language and the reading order. Clifton updated this package and fixed some bugs. Unfortunately, this project has remained inactive since 2012. Within the sigchi-latex code project, the SIGCHI 2014 organizing committee created specific MS Word and LaTEX templates with additional information for accessibility, and these have been updated regularly on GitHub, 14 with the last commit on January 2017.
After this SIGCHI initiative, the Tex users group (TUG) has devoted a specific page to show the resources needed for generating accessible PDFs [13]. TUG has also recently opened an active discussion on the conversion from TEX to PDF. This conversion is not either reliable or comprehensive yet. 15 Mainstream LaTEX authoring tools, such as Mik-TEX, generate by default a PDF without semantic structure. Without this structure, a PDF is not technically accessible. Moreover, the generated PDFs tend to miss blank spaces between words and have many reading order problems. Current research focuses on experimental tools 16 (refer to TUG mailing list for more information). Another option is to convert LaTEX documents into HTML or EPUB. This option has received a lot of interest [14][15][16][17][18][19] but currently does not solve conference proceedings.
In CHI 2015, a group of researchers volunteered to convert camera-ready PDF versions to accessible versions. They created a guide for authors. This guide asked the authors to provide them with alternate descriptions and embedded fonts, among other aspects. The authors had to generate accessible PDFs of their own papers and send them to the volunteers, who reviewed and repaired them. This experience is described in [3], where further information about time and costs of repairing and possible ways to outsource this work are discussed.
In 2016, some of the authors of [3], after additional experiences of creating and repairing accessible PDF proceedings, reflected on the complexity of the PDF format. In their view, it is not easy for neither authors nor the conference committee to create or afford to pay for accessible papers [20].
On a minor level of compromise, other conferences, like ASSETS 17 or ICCHP, 18 have published recommendations for authors with basic instructions on how to generate better PDFs from MS Word. SIGACCESS 19 provides a style guide on how to correctly mention in scientific publications disabilities and people with disabilities. CHI 2019 20 has recently published a detailed guide for accessible submissions, though the Aptara template and authors' workflow proposal have been a failure and have recently (July 2018) been withdrawn. It is worth mentioning that some journals in HCI, such as Universal Access to Information Society, 21 have also included specific accessibility recommendations in the instructions for authors, while others, such as RESNA, 22 have not done so yet.
Commercial and free tools intended to help authors to generate accessible PDFs are available. Examples include CommonLook, AxesPDF or PAVE [6]. PDFAxes has been publicized in several conferences [10,12,21]. These tools facilitate the preparation of better MS Word documents for accessibility and can also repair the final PDF.
In this paper, we contribute to this state-of-the art with the lessons learned in DSAI 2016, enriching the discussion on accessible conference proceedings in [3], and with a suggested integrated workflow for publishing accessible proceedings in an effective and efficient way. We argue in the results section and in the discussion that this workflow is needed to smooth the generation of accessible conference proceedings.

Case study: the DSAI 2016 conference
DSAI (Software Development and Technologies for Enhancing Accessibility and Fighting Info-exclusion) is a conference series devoted to technical innovations on products and services for people with special needs [13]. Since 2006, eight DSAI international conferences have been held. In 2016, DSAI became an ACM in-cooperation conference and its proceedings were published within the ACM Digital Library.
In this paper, we focus on the 7th edition (2016) of the DSAI conference, in which the first author was the publication chair. This edition attracted more than 50 relevant submissions (see Table 3).

Chosen formats and tools
The ACM submission process defines the format of original authors' submissions and final camera-ready versions of accepted papers. ACM promotes the use of MS Word and LaTEX. ACM provides authors with templates in these formats. ACM sets PDF as a compulsory output format. ACM accepts other output formats (such as XML) as long as a PDF version of the publication is provided too.
The publication chairs of DSAI 2016 wanted to include EPUB format as an additional, more accessible format. Yet, and due to time constraints derived from the publication of the proceedings in an accessible format, the EPUB format was not included. Based on accessibility requirements and the problems documented in the conversion from TEX to PDF, the authors of this paper selected MS Word Office Open XML (.docx) to be the accepted format for original submissions. Thus, Microsoft Office Word 2016 and LaTEX MikTEX were the main authoring tools.
During the conversion procedure, the publication chairs used Adobe Acrobat and Office Axes PDF. The authors also explored two additional tools: Adobe ® InDesign and Infty Editor.
For images, the authors decided to prioritize the JPEG format, as it is most similar to PDF image internal format and the most adopted one. To edit them, Adobe ® Photoshop (CC) and GIMP 2.0 were used.
The publication chairs reviewed the accessibility of the papers submitted to the conference by using the MS Word wizard, Adobe ® Acrobat DC accessibility validation tool and PDF Accessibility Checker 2.0.

Examples and thoughts during the conversion process
Fifty-nine (59) papers were submitted to DSAI. These papers served as a testbed for the conversion tools and the conversion procedure. In this section, some particular problems and the output of the process are discussed. First of all, the authors experienced difficulties which were unrelated to accessibility. Papers were submitted with an incorrect number of pages. Mandatory elements, such as DOI number, were missing too. Some authors asked to make some changes in the text after the review process. The version control was not fluid. The authors ended up working on old versions of the papers, especially in Special Tracks. This was a big issue, as it meant going forward and backward from the conversion process and carrying out over and over the same steps.
The authors processed the pictures provided in the submissions by using Gimp or Photoshop to deliver the appropriate resolution or to create a unique image from several grouped images. Three-hundred-and-forty-five (345) images were given alternative texts. Although the authors of the original submissions were informed to deliver alternative texts, the overwhelming majority of them did not provide this material, especially when the deadlines for submission were approaching. Consequently, initial conversion trials were very time-consuming. Some single pictures were in fact a collage of pictures. In this case, the resolution of the picture was increased and the collage pictures were joined into one (Figs. 1, 2, 3, 4).
Seventy-two (72) formulas were rewritten with MS Word formula editor, which is not particularly usable because it does not offer a straightforward editor. The symbols have to be added to the formula one by one (Fig. 5).
Once converted, the formulas were manually tagged as such in the final PDF.     Additionally, a manual review of the final PDF was done to check structure and reading order (Figs. 6, 7).
As already mentioned, 2016 was the first year the DSAI proceedings were published in the ACM DL. The committee did not know exactly the procedure to create, for instance, the subjects' metadata and to include copyright information. As a result of this, the required text box with the copyright information did not fit in the initial submissions. Thus, the publication chair had to change the layout/ template of the submissions-and conduct the generation and validation of accessibility again.
Eleven (11) papers were converted from LaTEX to MS Word. Fifty-nine (59) papers were reviewed in MS Word by normalizing reading order, author and title information, affiliation format, recreation of the subject matter in the correct format, heading hierarchy, table structure and alternative texts. Adobe PDF Accessibility tools and Access PDF validations follow up.
Fifty-nine (59) accessible papers were created and published in an accessible format in the ACM Digital Library. These papers were also published in a complete proceeding book. Although the process was not perfect, and there may be some problems in the reading of formulas and with some alternative text of the pictures, compared to previous editions, DSAI 2016 reached a high level of accessibility in its proceedings, with all papers of the conference being PDF/ UA compliant.

Lessons learned and a proposal for publishing accessible proceedings
This experience allowed us to realize that the traditional submission process is not suitable for creating accessible proceedings. Achieving this goal rests upon editorial work, additional steps and extra time, and a set of tools. There should be specific guidelines for authors, additional requirements for images, formulas and tables, and better templates. Most authors have learned to use the tools on a WYSWYG (what you see is what you get) basis and they rely on the final appearance. Most of them are not aware of accessibility requirements and how to meet them. Accessibility information has not clear affordances, and for example, it is not easy to see if an image has an alternative text or not. Accessible table requirements which imply simple and very structured tables are against widespread authoring practices.
There should be clear steps in the submission process that take into account the accessible reformulation, and reduce changes during the process. With current tools, as has been seen, the conversion and validation procedures require a lot of time. For this process to be efficient, it is necessary to start from a final and correct document.
A new figure in the conference organization is, drawing upon our experience, needed. This figure validates English correctness, length of the papers, required elements for accessibility, layout, and template guidelines before starting the publishing process. Failures to consider these aspects may require posterior editing of the submission and if the accessibility conversion has started it may imply repeating conversion and validation steps.
The authors should have the option to review their paper before the final camera-ready version, because sometimes the accessibility conversion may change a bit the layout or the presentation of images or tables, for example.
In an attempt to contribute to generate more accessible conference proceedings, the authors suggest: (1) creating a new responsibility in the conference organization that takes on the responsibility of accessibility and publishing, (2) reviewing templates sent to authors and information required from them; and (3) a clear communication strategy with authors.

New role and new submission process
The authors suggest that a publication and accessibility chair could be the person in charge of the publication process and of the final editing of the proceedings. This role will focus on all the steps related to the accessible publication of the conference proceedings, ranging from writing the instructions for authors and reviewing submissions to converting the submissions into an accessible version and conducting the accessibility validation.
The authors also suggest adding a new step to the submission process, just after the scientific acceptance of a paper. This new step is a formal review of the accessibility of the paper and, perhaps, should be a requirement for the final decision (accept or reject). After the accessibility requirements are fulfilled, the original paper is processed by the publication chair in order to generate the final paper (see Fig. 8).

Review of templates and information required to authors
The template for the conference should be reviewed in accessibility terms. The template should help the authors to create accessible documents. Working toward this end, the following information could be provided by the authors: • the original document in MS Word or LaTEX; • a document with a brief abstract (2 lines) including the most relevant data from any table included in the paper. This document is needed to create accessible tables; • a document with the LaTEX code of any formula included in the paper; • a document with a very short description (125 characters) for each picture or diagram included in the paper. This document should be provided in order to review its content and that it is different from the caption of the picture or diagram.
It is also important to provide a tutorial on how to create more accessible originals, since authors need support. This tutorial (a document or a video) should explain to the authors how to configure the correct settings in MS Word and how to add alternative texts. It should also give instructions for image resolution and simplification of tables and on how to write link anchors, describing best practices related to plain language and optimal images.

Effective communication with authors
The template and the new role in the organizing committee are not enough. Judging by our own experience, it is very important to establish fluent and effective communication with the authors of the papers, because some changes are made in their manuscripts during the process and they should review and confirm them, and also to collaborate in this process.
Before the submission, all authors should be informed about the intention of the conference committee to deliver accessible publications and about any additional requirements for the submissions. A template of the letter to the authors is provided: Starting this year, the Conference Organization Committee is working on the accessibility of the proceedings, and therefore we ask you to perform additional tasks to achieve this important objective.
Moreover, we ask you to try to avoid footnotes. We also ask you to submit 3 additional documents with important information: A final e-mail is also necessary to keep the authors abreast of aspects which could not be dealt with in the current submission and that could be considered for future manuscripts (see letter X in Annex I): Dear author, After reviewing the accessibility of your paper, the following issues were identified (

Discussion
The first question that arises from our experience is whether it is sensible to make such a big effort to publish accessible proceedings. The authors' answer is yes. Accessibility is a right and conference proceedings are an important source of scientific progress reporting. Nevertheless, accessible publishing is not possible without a collective effort involving all the stakeholders, including companies that create authoring tools, big publishers, conference organizers, authors, etc. A big claim should be made by the wider scientific community to have all the stakeholders engaged in accessibility. As we have seen, there is a correct and updated set of standards for accessible PDF (PDF/UA) and for EPUB (EPUB3) which include accessibility requirements. Unfortunately, authoring tools and widespread authoring practices have not kept pace with this evolution, and this is needed, as has been shown.
There is also room for considering whether this case study has used the best tools for the process and if it is generalizable to other conferences. In this case, the answer is a partial yes, because it has focused only on textual documents, which are the main publishing formats in conferences. The case study did not involve submissions including video, data or code content, which are increasingly common nowadays. This heterogeneity can be seen as another opportunity to work on and improve the accessibility of conference proceedings.

Conclusion
The main conclusion of our experience is that with the current authoring tools, it is not realistic-or even fair-to rely solely on the authors to create truly accessible PDF papers. Researchers need better tools to write and generate accessible PDF documents.
PDF authoring and conversion tools are not mature enough for an easy publication workflow. They require expert validation and review of converted documents. This article described non-evident limitations of the conversion process, and highlighted the semantic reduction in final tags. The final PDF is not yet optimized for viewing in tablets or mobiles.
Although there is also a lack of EPUB3 authoring tools, the transparency of this format may facilitate a better authoring and it may be desirable to deliver EPUB3 files in addition to the required PDF.
There is a need for an integrated workflow of generating accessible conference proceedings, which, the authors suggest, consists of four key elements: better tools, better communication between conference organization and researchers, better templates and instructions, and more awareness of accessibility.

Future research
The conversion from LaTEX and MSWord to PDF and EPUB needs further research. SIGCHI and TUG may offer some solutions.
Apart from basic textual proceedings, making video, data and code more accessible in conference proceedings should be taken into consideration in the near future.
More research is needed to test the resulting proceedings with assistive tools and people with disabilities to prioritize accessibility efforts.
The authors are currently working in improving Pandoc conversion from TEX to HTML, in order to be able to produce EPUB3 output from TEX sources.