Foreløpig resultat fra utredning om universell utforming av dokumenter i filformatene PDF og ODF

Transkript

1 Fakultet for teknologi og realfag Serviceboks 509 NO-4898 Grimtad Tel Fax Dr. Mikael Snaprud Tel Epost: Kristian Bergem Fornyings- og administrasjonsdepartementet Postboks 8004 Dep Oslo Foreløpig resultat fra utredning om universell utforming av dokumenter i filformatene PDF og ODF For publisering av innhold på nett er per idag HTML det mest tilgjengelige og mest utbredte dokumentformatet. Standardiseringsrådet foreslår: 1. Obligatorisk bruk av PDF (f.o.m. v1.4) for publisering av ferdigstilte dokumenter til presentasjonsformål på offentlige vevsider 2. Obligatorisk bruk av ODF for dokumenter på offentlige vevsider som har til formål å kunne utveksles/bearbeides I utredningen om konsekvenser for tilgjengelighet av et slikt pålegg, har vi satt opp 20 egenskaper for dokumentformater som har betydning for universell utforming av elektroniske dokumenter. Et foreløpig resultat er basert på 12 av dem som vi valgt som mest grunnleggende. Foreløpige resultater fra evaluering av PDF (v.1.7) og ODF (v.1.1) formater gjennom studier av spesifikasjoner følger i Vedlegg 1. Vedlegg 2 definerer alle 20 egenskaper. Denne foreløpige vurdering viser at både ODF og PDF har 11 av de 12 egenskapene som er identifisert som mest vesentlig for universell utforming av elektroniske dokumenter. For ODF har vi ikke klart å verifisere at formatet kan angi en sekvens for lesing av tekst avsnitt (se Property 3.2 i Vedlegg 2). Dette kan være vesentlig for lesing av et dokument med flere spalter med en skjermleser. PDF formatet vil ikke enkelt støtte en restrukturering av et dokument for eksempel for å vise det på en liten PDA skjerm uten mye scrolling. (Se Property 3.6 i Vedlegg 2.)

2 Når det gjelder bruken av både ODF og PDF formater, vil vi imidlertid gjøre oppmerksom på at, selv om universell utforming er støttet av et dokumentformat på en tilsvarende måte som for HTML, er det altid mulig å lage dokumenter med betydlige barriærer. Det er derfor også for PDF og for ODF avgjørende for resultatet at retningslinjer for universell utforming av dokumenter utarbeides og følges. Før utredningen kommer til en endelig konklusjon vil vi også med aktuelle brukerorganisasjoner drøfte en liste over dokumentformategenskaper som kan sees som grunnleggende for universell utforming av elektroniske dokumenter. Etter drøftingen vil listen da brukes til en grundig gjennomgang av ODF og PDF formatene, inklusive lab studier av publiseringsverktøy. Det her presenterte foreløpige resultatet er utarbeidet i samarbeid med Dr. Agata Sawicka og Patrizia Bertini, begge ved Universitetet i Agder. Arbeidet med denne utredning ble påbegynt 25.Oktober og er planlagt avsluttet 15 Februar. Vi vil også i denne sammenheng vise til muligheten for å innføre tettere rutiner for publisering og overvåkning av hva som blir publisert for å sikre mer tilgjengelig innhold. Dette er skissert i Vedlegg 3. Grimstad Dr. Mikael Snaprud Førsteamanuensis IKT Universitetet i Agder

3 Vedlegg 1 Foreløpige resultater Resultat fra foreløpig vurdering av ODF 1 No Property ODF Explicit document structure with headers [1] : Markup for paragraphs [1] : Represent textual content as text yes 2.1 Alternative text for images [2] : 6, [6]: Alternative text for links [1] :60-61, [6]: Natural language tags for paragraphs 3.2 Tags for reading sequence for multiple columns not found 3.4 Explicit character set information [6]: Font information to allow resizing of the characters OO experiment confirm Document layout to allow for visual reorganisation 3.6 [5] : Free software to view the document format 4.3 Openness [1] :61, [6] :64, OOo: via fonts OpenOffice, KOffice, Micros oft Office with plug-in + s everal more OASIS s tandard, free and acces s ible s oftware Kilder: (lastet ned senest ) [1] OpenDocument v1.0 (Second Edition) specification was approved as a Committee Specification on 19 July 2006.:66. See: [2] R. Schwerdtfeger & C. Asakawa, Gap Analysis of ODF v1.0 Accessibility. See: pdf [3] How Was Accessibility addressed in Open Document v.1.1? [4] How well do OpenDocument applications address the needs of people with disabilities? [5] Accessibility Guidelines for s of Open Document Format v1.1 [6] Open Document Format for Office Applications (OpenDocument) v1.1. See 1 Se Vedlegg 2 for en fulstendig definisjon av egenskaper.

4 Resultat fra foreløpig vurdering av PDF 2 No Property PDF Explicit document structure with headers [7] : Markup for paragraphs [7] : Represent textual content as text yes 2.1 Alternative text for images [7] : Alternative text for links [7] : Natural language tags for paragraphs [7] :58, Tags for reading sequence for multiple columns [7] :601, [7] _901, [7] : Explicit character set information [7] ; , uses UTF Font information to allow resizing of the characters [7].682 Document layout to allow for visual reorganisation 3.6 not clear how to achieve this 4.1 Free software to view the document format 4.3 Openness ISO standard in 1.4, later versions underway Kilder: (lastet ned senest ) [7] PDF Reference. Sixth Version. V November OpenOffice + more to generate (v 1.4), xpdf + more to read 2 Se Vedlegg 2 for en fulstendig definisjon av egenskaper.

5 Vedlegg 2 Foreløpig liste over 20 dokumentegenskaper Cluster 1:Document structure...5 Property 1.1:Explicit document type declaration...5 Property 1.2:Document schema for evaluation...6 Property 1.3:Explicit document structure with headers...6 Property 1.4:Markup for paragraphs...7 Property 1.5:Markup for lists...7 Property 1.6:Markup for images...7 Property 1.7:Markup for tables...8 Property 1.8:Separation between content style and structure...8 Property 1.9:Represent textual content as text...8 Cluster 2:Non-text element descriptions...9 Property 2.1:Alternative text for images...9 Property 2.2:Alternative text for links...9 Cluster 3:Document conversion support elements...9 Property 3.1:Natural language tags for paragraphs...9 Property 3.2:Tags for reading sequence for multiple columns...10 Property 3.3:Identify destination of links...10 Property 3.4:Explicit character set information...10 Property 3.5:Font information to allow resizing of the characters...10 Property 3.6:Document layout to allow for visual reorganisation...11 Cluster 4:Use and maintenance...12 Property 4.1:Free software to view the document format...12 Property 4.2:Assistive technology support...12 Property 4.3:Openness...12 Cluster 1: Document structure Property 1.1: Explicit document type declaration Document format needs to declare the document type in an explicit and unambiguous way. Typically the file name extension will indicate the document format and the file header will include the information on format version etc. Document formats may not require explicit declaration of the actual format in the document file.

6 The declaration will facilitate parsing of the document for any processing including viewing and it will enable more accurate evaluation against a schema. Property 1.2: Document schema for evaluation A document schema is needed to support automated formal evaluation of the documents Several XML based formats provide a schema for the evaluation. There are even initiates to evaluate a schema. 3 Incomplete schema requiring additional external entity descriptions, such as character sets. Automated evaluation can create more awareness among tool developers to support users in the authoring process. Ideally the evaluation against a schema should be the basis for any tool implementation. Property 1.3: Explicit document structure with headers The document structure need to be represnted by explicit headers. The format will need to support several levels of headers. the format specification. Headers are formatted manually, e.g. as bold or underlined, but remain defined as body text. Without an explicit definition of header styles, the document structure cannot be efficiently used, impeding the manual navigation, where a user can jump from heading to heading, and the automatic indexing,where e.g. search engines use heading to detect the essence of a text. 3

7 Property 1.4: Markup for paragraphs A paragraph will structure the main text of a document Tags to open and close paragraphs the format specification. Proper use of paragraph markup can be useful for accessing only the paragraphs to updating the document. Failing to close a paragraph can cause confusion for navigation of the document. To indicate a portion of text provided in a certain natural language, and for navigation. Property 1.5: Markup for lists Document format needs to allow for numbered and bulleted lists. Tags to represent lists the format specification. Correctly used, the number of headings and items in lists can be reported by a screen reader, and useful for navigation. The screen reader can report the number of items in a list. Property 1.6: Markup for images Document formats need to support explicit representation of non text elements Tags to represent images, video, etc. the format specification. Images that are not identified may be a barrier to navigation or for accessing the actual content of the document

8 Property 1.7: Markup for tables Table markup can identify headers and rows of a table the format specification. the format specification. Tables that are not identified may be a barrier to navigation or for accessing the actual content. Property 1.8: Separation between content style and structure Formats are often composed of layers that can be processed separately Mixing content, layout and structure Introduces significant barriers Property 1.9: Represent textual content as text Document formats should represent textual content as text Text can be represented as scanned images or as text Allowing a format to represent a text as only as image Any text represented only as image will not be accessible

9 Cluster 2: Non-text element descriptions Property 2.1: Alternative text for images Document formats should support a textual description associated with images Tags for associated text the format specification. Missing text for images may render the document inaccessible. A distinction between purely decorative images and images useful to access the meaning of the content would be useful. Property 2.2: Alternative text for links Links should as far as possible be descriptive. However, if the link cannot be descriptive an alternative text describing the link can be provided. Tags for associated text Formats that support links may not have not support alternative text for them A description of the link destination can facilitate navigation. Sometimes the link itself does not give any information and the displayed text may not help navigation e.g. read more. Cluster 3: Document conversion support elements Property 3.1: Natural language tags for paragraphs Document format needs to represent the natural language of the content. Natural language tags associated with the whole document or some portion of it the format specification. Not used or wrong encoding. A screen reader reading a document aloud will be very hard to understand if the voice language does not match the language of the content.

10 Property 3.2: Tags for reading sequence for multiple columns Document formats often support the representation of multiple columns. To enable AT to read this correctly a reading sequence can be helpful. Tags to indicate the reading sequence of content. The document format may not support this. A screen reader may try to read across multiple columns row by row. Property 3.3: Identify destination of links The destination of a link in a document may need some additional information. Tags associated with links for additional information The document format may not support this of the destination should indicate if the link is internal to the document, and if the linked resource is of some other type than the current one. Property 3.4: Explicit character set information The format will need to allow for a reference to the character set in use to support character extraction. Tags associated with any textual element A format that allows references to character sets that are not openly available may result in barriers to reading a document. If the font needs to be replaced by an alternative character set then e.g. national characters may be missing. Property 3.5: Font information to allow resizing of the characters The format will need to support resizing of the font size. Tags associated with textual elements and open specifications of character to support different styles. Use of fonts that do not scale well. Hard to read characters with rough edges.

11 Property 3.6: Document layout to allow for visual reorganisation The format should allow for visual reorganising the elements of a document to support different screen sizes and zooming of the content. A separation of content from style such as Cascading Style sheets (CSS) for HTML. Fixed instead of relative positions of characters and blocls of text and non-text elements If this is not supported then reading a document on a small screen may require excessive scrolling or result in several elements on top of each other.

12 Cluster 4: Use and maintenance Property 4.1: Free software to view the document format Document format needs to be supported by a freely available software. A free viewer can be provided for download or as a web service converting the document into (X)HTML for access through a web browser. Reference to non-free characters sets or other proprietary technologies from the document will disallow development of free software for using the format. The accessibility properties and functionality of such viewers are varying. Property 4.2: Assistive technology support Document format needs to be supported by a freely available assistive technology (AT) software for all disability types. Documents are usually not accessed directly by AT, they are rather accessed through a viewer such as a web browser or an authoring tool which in turn should support AT. The user interface design of the software that can be used to access the format may not be enabled to interact with AT. Implications are rather for the software used to process the formats than for the formats themselves. Property 4.3: Openness Document format needs to be complete, self contained and freely available to ensure that independend developers can implement different kinds of software to use it creation of documents/retrofitting, validation/evaluation, and further development. An open process for the development of the specification is needed associated with a clear patent policy to ensure that any patents contained are royalty free, such as for the policy adopted by W3C. 4 An open document format will also benefit from open source example implementations, and 4

13 validation test suites. An open format cannot depend on any proprietary technologies for its use or implementation. However, vendors may chose to implement proprietary tools to use the open format. Binary formats are hard to use for a third party to create any kind of software tool, unless the specification is open. Failing to publish the specification will hinder innovation for users driven by their choices among competing products using the same format. Failing to comply with the openness will result in fewer implementations related to the format. A reduced market pressure is likely to result in a slower development of more accessible solutions. One practical example in Norway is that the first text processing software to support the 'Nynorsk' was OpenOffice.

14 Vedlegg 3 Forslag til evaluering og forbedring Evaluering før publisering Eksisterende programvare, både proprietær og åpen, kan utvides med tilleggsmoduler for ulike formål. For eksempel har Sun Microsystems utviklet en plug-in 5 som gjør det mulig å bruke formatet ODF1.1 med Microsoft Office. På tilsvarende måte kunne en annen tilleggsmodul utvikles for å teste tilgjengeligheten til dokumenter før de blir publisert. Alternativt kan en test tjeneste integreres i publikasjonsverktøy for portaler, eller som en tjeneste på nett hvor brukere kan laste opp dokumenter som skal evalueres. Monitorering av publiserte dokumenter Mange av de offentlige dokumenter som er publisert så langt har stort potensiale for tilrettelegging for økt tilgjengelighet. En tjeneste som monitorer publiserte dokumenter kan finne ut mer om hvilke dokumenter som har barriærer slik at de kan bli korrigert. Forbedring av utilgjengelige dokumenter En tredje type verktøy som kan brukes i denne forbindelse er støtte for utbedringer av barriærer. Slike verktøy kan lokalisere mulige barriærer og foreslå utbedringer, f.eks. ved hjelp av OCR for å identifisere hva som er overskrifter i et dokument som kun foreligger som scannet bilde. 5