This extended abstract is a contribution to the Easy-to-Read on the Web Symposium. The contents of this paper were not developed by the W3C Web Accessibility Initiative (WAI) and do not necessarily represent the consensus view of its membership.
This position paper discusses the feasibility and a possible structure to include "Plain Language" or "Easy to Read" into the process and workflow of Web-engineering regarding
Following studies of Web-Engineering workflows and experiences out of day by day practice, legibility and readability in most cases are treated as an additional or parallel activity, comparable to the concept of (screen reader) accessible "extra pages" we had more than a decades ago. Most often customising text is recognised as a requirement for content development - a follow up of the design and implementation phase, neglecting the need for addressing those requirements already in structure, design, navigation, look and feel, functionality and layout. Legibility and Readability is meant as both, a service for a specific user group (people with cognitive disabilities) and at the level of general readability (e.g. "Plain Language" use) nevertheless lacking the state of a general requirement of Web Accessibility. To avoid inefficiency, inaccessible websites and extra costs, those new aspects demand for early planning and inclusion in the Web Development process. Moving legibility / readability from an add-on or posterior activity to an integral part of the Web Engineering process will evolve accessibility.
Besides this inclusion into the "meta-workflow" of web-engineering, usage of plain language and Easy to Read ask for efficient and effective authoring support in daily practice and a framework ensuring the best possible implementation from planning till end user testing.
Modern accessible web design considers the needs of a broad range of users with and without disability. However, during the development of accessible web pages, typical checks involve technical criteria like WCAG 2.0 [WCAG] and may lack of involving people and first and foremost accessible content. This excludes a huge number of people. International studies show approximately 25% of grown-ups without full literacy proficiency [Nomura; Grotlüschen] asking for accessible content that is easy to read and easy to understand. Within this group are many people with cognitive disabilities having a permanent need for accessible content, clearly structured design, navigation and content presentation that are only in reach when thought of and implemented from day one of the web design process - even more as ICT and the web became standard in our society and more and more "non-techy" people evolved from users to authors and content providers.
Experts outline that at least 10% of the web design and development resources should be invested in usability at all stages and in particular in early stage [Nielsen]. This helps to avoid expensive re-design, maintenance and repair. [e.g. Gilb]. Similar requests are underlined for web-accessibility [Pühretmair]. There is no reason to approach Legibility and Readability differently. Easy to Read on the web as a specific requirement of a big group of web users should be treated as part of the web Engineering process.
A possible design workflow that comprehensively supports accessibility can be split into four major steps [DSAI 2012]:
Attractiveness and usage of a web page depend on the users' perception of and satisfaction with it. Thus, the identification of the target group(s) and their requirements at the beginning of the process plays a major role and should cover technical accessibility as well as visual design, look and feel, and textual content. This asks for close interaction between requirement analysis and graphical design in requirement definition, e.g. in templates or guidelines for Software Requirements Specifications (SRS), both for functional and non-functional requirements: e.g. [IEEE] in order to develop a solution that meets the users' needs and expectations.
Even the use of "technically" accessible templates may not be sufficient, lacking adequate support for people with various "reading" disabilities. Following this, significant improvements regarding accessibility and usability ask for "rapid prototyping"-like user tests with at least one person of each target group, comprising checks for the following issues:
Accessible content generation asks for specific efforts. To create "Easy to Read" content, a review carried out by 3 to 5 users and assisted by a person without a cognitive disability is essential. The content review comprises the text/information itself as well as its integration in the layout, navigation, search functions and login functions.
Additionally, information design got overwhelmed by graphical/layout aspects driven by marketing requirements during the last years. Basically, graphical design is a powerful tool to provide better access to complex or unstructured data [Jacobson] and demand for user involvement and user testing of all alternatives and prototypes under discussion.
As a last step the whole Web page including a final web accessibility check can be generated. A further change of the Web page (i.e. new page, new content) will cause rework and possibly a new throughput concerning accessible content generation.
Analyses showed that, concerning the (meta-) workflow of web engineering and the micro-workflow of Easy to Read:
Involving legibility and readability into web engineering will improve Usability and Accessibility in general but also underlines that very specific needs of people with cognitive disability will remain subject to specific services, be it assistive technology or personal support. Plain language might be able to enter the general set of usability requirements, guidelines and tools as long as it supports usability.