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.

Including Easy to Read, Legibility and Readability into Web Engineering

1. Problem Description

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.

2. Background

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.

3. Possible Approach

A possible design workflow that comprehensively supports accessibility can be split into four major steps [DSAI 2012]:

Design and Requirement Analysis, Requirements Engineering

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.

Accessible Web Design and User Tests

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

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.

Web Site Launch and Operation

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.

4. Challenges, Outcomes and Future Research

Analyses showed that, concerning the (meta-) workflow of web engineering and the micro-workflow of Easy to Read:

  1. Web engineering models allowing early user involvement, testing and feedback in several iterations are more capable of taking usability requirements on board [Kappel]. The same is outlined for web accessibility [Petrie].
  2. Analyzing Easy to Read aspects will propose solutions to problems going beyond pure content authoring aspects, having impact on any page and information displayed to the user.
  3. Legibility and Readability have to become an integral part of the WAI guidelines and tools. This inherits the known problems of web accessibility take up in practice but avoids fragmentation in the web accessibility domain. So far, these issues are discussed and treated as after-design/development and content authoring domain.
  4. Implementing Legibility and Readability has to support the request to better include web accessibility into the web engineering process.
  5. Besides all positive impact and effects the full-blown "Easy to Read" framework / process could turn out as too complex / specialised to be included within general web accessibility requirements and guidelines whereas Plain Language seems to be already "on the agenda" and better mainstreamed, fulfilling basic legibility / readability requirements and preparing the ground for further adaptation into Easy to Read.
  6. Easy to Read for specific groups of people with cognitive disabilities turns out more as a specialised profession and service to be made available on demand. It seems to overcharge mainstream as it is seen in the reluctance and problems in taking up even the most basic web accessibility requirements.
  7. Implementing Plain Language and Easy to Read asks for research and discussion of automated tools helping with analyses (grammar/semantic as well as navigation/interaction) interaction / navigation and information design (annotation, enrichment and alternative means of knowledge representation) in order to support users and authors of web content [Nietzio].

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.


  1. Cooper, Alan et al (2007). The Essentials of Interaction Design. Indianapolis, Indiana, Wiley
  2. Matausch, K., Peböck, B., Pühretmair, F. (2012). Accessible Content Generation an Integral Part of Accessible Web Design, 4th International Conference on Software Development for Enhancing Accessibility and Fighting Info-exclusion, DSAI 2012, Book of Abstracts, ISBN 978-989-704-089-4, Portugal: UTAD - University de Trás-os-Montes e Alto Douro, pp.59
  3. Gilb T. (1998). Principles of Software Engineering Management, Addison Wesley, Reading, MA.
  4. Grotlüschen, A. , Riekemann, W. (2011). leo. - Level One Study, Literacy of adults at the lower rungs of the ladder, Press brochure.
  5. IEEE. Recommended Practice for Software Requirements Specifications (IEEE Std 830-1998, Revision of IEEE Std 830-1993).
  6. Jacobson, R (2000). Information Design, MIT Press.
  7. Kappel, G. et al (eds.)(2006). Web Engineering - The Discipline of Systematic Development of Web Applications", John Wiley & Sons,
  8. Nomura, M., Nielsen, G.S., Tronbacke, B. (2010). Guidelines for easy-to-read materials, IFLA Professional Reports, No. 120, International Federation of Library Association and Institutions.
  9. Nielsen, J. Usability 101: Introduction to Usability.
  10. Nietzio, A. (2012). How long is a short sentence?, In: Miesenberger, K.; Karshmer, A.; Penaz, P.; Zagler, W. (eds): Computers Helping People with Special Needs; Proceedings of the 13th International Conference ICCHP 2012; Springer Heidelberg, p.369 ff.
  11. Petrie, H. et al (2007). The Relationship between Accessibility and Usability, in: CHI 2007 Proceedings: Empirical Studies of Web Interaction, ACM, San Jose.
  12. Pühretmair, F., Miesenberger, K. (2005) Making sense of accessibility in IT Design - usable accessibility vs. accessible usability, in: Tjoa, A., Wagner, R.: DEXA 2005; Database and Expert Systems Applications, Proceedings of the Sixteenth International Workshop, Copenhagen, Denmark, IEEE Computer Society, Brussels.
  13. Shneiderman, B. (1987). Designing the User Interface, Addision-Wesley Publishing Company, Reading, MA.
  14. W3C/WAI. W3C Web Content Accessibility Guidelines 2.0 (WCAG 2.0).