Interview with eDiscrimination website development organisation.
The combating eDiscrimination project website was not originally intended to become a central element in the research process. Rather, it was originally planned as a research output, IE an exemplar of good accessible web design. However, due to the difficulties encountered making the site accessible for the HAL screen reader, the development of the project website became more regarded as a matter of process. The choice of the HAL screen reader was a practical decision, as one researcher was dependent on this access equipment to use computers.
As discussed above, the project website was designed to serve several purposes: to act as a repository of articles produced from the project, a holder of multiple links to other potentially useful sites for disability related issues, an information holding site of user tester demographics, a test site for gauging basic user tester internet competence, and a user tester feedback interface. Hence in addition to static text, the site was required to host a standard search facility, and a user tester section where registration was required, which then allowed user testers to join the project. The user tester section has a series of questions to be answered through the selection of yes/no radio buttons, and fields to allow the input of individual data such as email address etc. So, although there were several different elements to the website, there is nothing on the site that has not been produced on countless others. At the time the website was required, the University did not have sufficient capability to build the site ‘in-house’, hence the decision was made to put the development of the website out to competitive tender in May 2007.
Three companies were asked to provide quotations against the same specification for the project website. All three bid for the work, and the successful company’ Fluid creativity’ was commissioned in June 07. It was a difficult decision to select a company, all three provided competitive prices, and all three had sites they had produced for other companies checked using a HAL screen reader for accessibility, which all had passed. Ultimately the final decision to place the order rested on practical decisions. The company was relatively local and had won awards from the Manchester Digital trade association for the accessibility of its internet sites.
After the order was placed, technical and financial members of the company were invited to a meeting in the University where detailed discussions took place regarding specific requirements for the website which included all elements of the site including content management suite to be capable of use through the HAL screen reader. The company stated their commitment to accessibility of websites and suggested our request was not problematic, as in their opinion, all websites the company produced were by default to a high standard of accessibility. This point was reiterated by the senior web developer from the organisation Jaik, who in a later interview commented:
"e;The way we put things together anyway it is all included rather than an additional cost for making something accessible... It does not take any longer to do it the right way. It is just, obviously, the knowledge to actually do it right in the first place."e; (Jaik, Fluid creativity)
There are two issues Jaik expresses here: firstly, there is no additional cost in making websites accessible if done professionally initially; secondly, accessibility will follow from applying professional standards.The company was fully aware that screen readers were to be used to check the site but never expressed a need to test any elements of the site with screen reader users before launch. This does not reflect any criticism on Fluid Creativity or Jaik himself as a senior web developer. Rather it reflects a view found in the majority of web developers interviewed for this research who believed accessibility could and does arise from a professional approach to development and adherence to accessibility guidelines:
"e;it does not take us so much more work, if any more work to make it accessible... so why not just do it?... We try to make them as accessible as possible."e; (Company A: 7)
"e;We need to do a little bit of research on guidelines… It’s making sure that stuff within the code of the page doesn’t stop things from reading the text. That is what is important. That is where your screen reader is."e; (PS C: 7)
"e;They provide really good guidelines on what measures should be taken to make sure our website is accessible."e; (PS F: 6)
"e;They just need accessibility to be taken hand in hand in the design, that way it will work well."e; (PS B: 8)
Hence it would be incorrect to argue the position Fluid Creativity adopted regarding the ease of producing accessible websites was unique. It was only when the organisation believed the website was ready for launch that the first element of user testing appeared and problems arose surrounding the inaccessibility of the site for HAL screen readers. Much of the following is drawn from email correspondence between the University and Fluid Creativity over testing the website. Initially, it was thought the area of most concern would be the accessible contents management suite.
"e;I’ve been having a look for other WYSIWYG editors (which are the only ones that will automatically generate the HTML for you) that are accessible, but I’ve found nothing. If we just use a plain text box with no HTML code then obviously it will limit the formatting that can be done to just paragraphing."e; (Jaik, Sept 07)
No WYSIWYG editor was found that could be regarded as accessible. However, writing html code is not an accessibility issue, so although standard WYSIWYG could not be used and is therefore inaccessible, this does not mean an accessible alternative was not possible. The issue here is the time that was initially spent looking unsuccessfully for what eventually proved to be a fruitless task. Although the organisation had produced accessible websites previously for a number of clients, clearly the definition of accessibility did not extend to issues of site management. Although the CMS was made accessible as noted above, the more problematic issues occurred when the site was required to interact with disabled user testers.
As a static site containing information and general articles, accessibility proved easily accomplished. The first problematic area arose when the search facility was accessed by the screen reader. Dropping on to the search facility simply froze the screen with the only option being to reboot the computer. This event happened on every occasion the search facility was attempted with eventually the search option being removed from the site until much later when it was resolved with the assistance of the screen reader manufacturer ‘Dolphin computer access’. After the issue had been resolved Jaik explained the problems from his perspective:
"e:I don’t know exactly the cause of it, but it appears to be some incompatibility between the screen reader software and one of the plug-ins that is installed in Internet Explorer. When it hits on a certain combination of html, it just seems to trip it over. Its one of these one in a million bugs that have a certain combination or condition that cause something to freeze up."e; (Jaik, Nov2008)
Jaik continued to advise that he had been in contact with the technical experts at ‘Dolphin’, who claimed never to have come across this particular problem before and again the consensus appeared the event was a fluke of incompatibility between the html used in the search engine and the screen reader programme:
"e;We tried the obvious things and it wasn’t any of them. But it turns out it was just some very rare incompatibility between the screen reader and another plug-in that is installed. Actually the bit that was tripping it up was only a piece of html code. We found it and tried changing it and it still tripped it up. If we had enough time to spend on it we could just trial and error through every combination and narrow it down a bit."e; (Jaik Nov2007)
The issue which is identified here and will be returned to later, is that making websites accessible is not guaranteed simply by following guidelines or adopting best practice coding methods. In this example, an established web developer practiced in using accessibility guidelines and html coding techniques together with the manufacturer of a commercially successful screen reader both had difficulty in tracking down and correcting a serious accessibility conflict on a website. It was only at the point where a screen reader user tested the site and found the problem that it surfaced as an extremely problematic accessibility issue which required addressing. As noted above, while the search facility was being resolved, the function was removed from the site to allow further development and testing to take place. Once more, serious accessibility issues arose which illustrated the conflict between accessibility guidelines and the practical usability of the website.
One section of the website was intended to be used by disabled computer users to firstly provide proof of their internet capabilities, and secondly to generate data on the accessibility of employment related websites that were commercially operating on the web. To achieve these objectives, the website was required to collect information from user testers. From a technical perspective, the data collection required two methods of user tester interaction. Firstly, edit boxes were needed to allow user testers to fill in personal details such as name and email address; secondly radio buttons were required for answering simple binary opposites. For example the question, “Do you define yourself as disabled?” Had two check boxes for answers, ‘Yes’ and ‘No’. For people who do not use a mouse to position the cursor, activation of the appropriate check box is achieved by pressing the keyboard space bar when the desired answer is arrived at using the keyboard up or down arrow keys to navigate. Although entering data in text boxes never caused any accessibility problems, finding a method to allow access to the questions and radio button answer selection again proved extremely problematic. In brief, the screen reader could not initially read the related questions which required check boxes to be selected. Hence as the screen reader was moved down the webpage, it simply announced ‘Yes’, ‘No’, repeatedly without reading the related question to be answered.
There are guidelines and published techniques for ensuring that the coding behind checkboxes and radio buttons work with screenreaders, involving labelling and specific code ordering. However, the problem of reading a question and then providing radio selection buttons as responses was not in itself a simple issue of appropriate coding. After multiple unsuccessful attempts to solve the problem within the site, Jaik returned to a simple basic one page of html coding with one question: ‘Do you like rabbits?’ with two ‘Yes/No’ radio buttons for responses. This single webpage worked perfectly with the screenreader, but when this code was incorporated into the full website the problem returned.
Coding up forms according to the guidelines, in short, worked fine in isolation, and the screen reader had no problems interpreting it properly. Within the design that had been produced, however, properly positioned using Cascading Style Sheets with structural html, the form ceased to work. An unusual, technically valid but counter-intuitive coding structure needed to be adopted, before the screen reader would work with it. In this case the code that actually worked could not be described as structural html, thereby rendering most keyboard shortcuts unusable, and was on the contrary – to the eye of a web accessibility specialist - rather clumsy-looking code, yet more accessible than the original more guideline-compliant code had been.
This points to what must clearly be one of the most important findings of this part of the project:
In the context of CSS positioned designs, unplanned-for anomalies, about which there is no mention in any specification or guideline on the W3C, may arise, rendering otherwise compliant code in practice inaccessible. Making the code accessible may require counter-intuitive recoding that whilst validating against specifications may run counter to the letter of the guidelines. This is most common in the case of more complex code structures such as HTML forms.