How Accessible is the Process of Web Interface Design?
Kirk Norman, Yevgeniy Arber, Ravi Kuber · 2013 · Proceedings of the 15th International ACM SIGACCESS Conference on Computers and Accessibility (Assets '13) · doi:10.1145/2513383.2513385
Summary
This short paper investigates the accessibility challenges faced by blind web interface developers through interviews with six legally blind participants (all male, aged 29-48) who had experience building websites and online applications. Five used JAWS as their primary screen reader, and one alternated between JAWS and NVDA. Two were congenitally blind while four lost sight later in life. All identified as intermediate to expert screen reader users. The study examined how blind developers write and verify code, handle spatial layout, use scripting languages, and collaborate with sighted colleagues and clients. The interviews were conducted by telephone or video conference and covered assistive technology use, coding experience with HTML and scripting languages, and strategies for designing interfaces for both blind and sighted audiences.
Key findings
All six participants favored simple text editors like Notepad for coding HTML rather than visual web development tools like Dreamweaver or Frontpage, which were found to be inaccessible due to their reliance on drag-and-drop and mouse-oriented interactions. Participants described a time-consuming verification workflow: continuously switching between the text editor and web browser to check that all objects appeared correctly — images, hyperlinks, table contents, lists — and that no items seemed out of place. To reduce coding errors, participants memorized large sections of HTML and scripting code or created reusable template files, since basic text editors lack features like autocomplete or automatic tag closure. Spatial layout was a particular challenge — participants were aware that content needed to be visually arranged for sighted audiences but struggled to achieve this through a screen reader. Strategies included using JAWS Screen Layout mode, keeping sighted-designer-created CSS files on hand, and using CMS platforms like Drupal. JavaScript was problematic because screen readers had difficulty interpreting JS output, making it hard to verify whether scripting code worked correctly. In collaborative settings, the lack of synchronization between visual and non-visual page representations hindered working with sighted developers and clients, especially during on-the-fly prototyping.
Relevance
This paper addresses a rarely studied population: blind people who create web content rather than just consume it. The findings reveal that the tools of web development are themselves inaccessible, creating a professional barrier for blind developers. The reliance on memorizing code, inability to use modern IDEs, and difficulty verifying visual layouts put blind developers at a competitive disadvantage. The design implications identified — editing tools that convey object layout information, synchronization between visual and non-visual presentations, non-visual methods for conveying code structure (like syntax highlighting equivalents), and autocomplete for reducing memory burden — remain largely unaddressed a decade later and are relevant to modern IDE accessibility discussions. For the accessibility community, the paper highlights an irony: the people best positioned to create accessible websites (blind developers who understand screen reader behavior firsthand) face significant barriers in the development process itself. The collaborative design challenges also speak to the broader need for accessible design tools that support inclusive teams.
Tags: blind developers · web development · screen readers · programming accessibility · JAWS · collaborative design · HTML · CSS · JavaScript · workplace accessibility · developer tools