Accessibility in Non-Professional Web Authoring Tools: A Missed Web 2.0 Opportunity?
Christopher Power, Helen Petrie · 2007 · Proceedings of the 2007 International Cross-Disciplinary Conference on Web Accessibility (W4A) · doi:10.1145/1243441.1243468
Summary
This paper from the University of York evaluates the accessibility of Apple's iWeb, a non-professional web authoring tool representative of a new generation of Web 2.0 design applications aimed at non-technical users creating personal websites, blogs, and photo albums. The authors argue that these tools — being developed from scratch rather than retrofitted from earlier designs — represented a unique opportunity to integrate accessibility from the beginning. The evaluation examined both the accessibility of content produced by iWeb (output accessibility) and the accessibility of the iWeb interface itself (tool accessibility) using VoiceOver screen reader on Mac OS X. The paper contextualizes the evaluation with data from a UK Disability Rights Commission study that found only 19% of 1,000 tested websites achieved WAI Priority 1 conformance, and only 76% of 913 website tasks could be completed by disabled users. Critically, only 55% of problems identified during user testing were covered by WCAG guidelines, reinforcing that compliance is necessary but not sufficient. The authors note that 69% of WCAG checkpoint violations require qualitative evaluation by the author — something non-professional users are untrained to perform — making it imperative that tools produce accessible output by default.
Key findings
The evaluation revealed fundamental accessibility failures in iWeb's output: no mechanism to add alternative text to images or multimedia within the interface (except photo page captions); visual headings rendered without semantic heading tags (h1, h2); bold and italic text implemented via purely presentational CSS rather than semantic em/strong tags; navigation bars rendered as graphics without alt text despite appearing textual; and hard-coded div sizes causing text to overlap or disappear when browser text size was increased. The iWeb interface itself was largely inaccessible to screen reader users: focus was not announced on application startup; the content editing panel was reported only as "Scroll Area" with no navigable components; non-text content could only be added via mouse interaction; and control buttons and the Inspector Panel were unreachable without point-and-click. The paper proposes three solutions: developer education to integrate accessibility into tool developer training; best practice integration where templates use proper semantic HTML (heading tags styled with CSS) and the interface provides alt text entry fields; and non-professional education where the tool itself teaches users about accessibility (e.g., a "Click here to find out why this is important" link next to the alt text field).
Relevance
This paper articulates a concern that remains acutely relevant: as web content creation becomes democratized through easy-to-use tools, the accessibility of those tools determines the accessibility of a growing proportion of the web. The "missed opportunity" framing is powerful — tools built from scratch have no excuse for missing basic accessibility features that must be retrofitted into legacy tools. The dual evaluation approach (output accessibility and tool accessibility) established an important methodology: a tool must both produce accessible content and be usable by authors with disabilities. The three-tier recommendation (developer education, best practice integration, non-professional education) provides a practical framework that applies directly to modern tools like Squarespace, Wix, and social media platforms. The vision of authoring tools as accessibility education vehicles — teaching users why alt text matters while prompting them to add it — anticipates features now appearing in some modern content platforms. The paper also reinforces that automatic conformance checking alone cannot solve non-professional authoring accessibility, because most checks require human judgment that untrained users cannot provide.
Tags: web accessibility · authoring tools · WCAG compliance · Web 2.0 · semantic HTML · alternative text · screen readers · content creation · accessible by default
Standards referenced: WCAG 1.0 · WCAG 2.0 · ATAG 1.0