Accessible [Google] Search Engine
Search engines are likely the most powerful tool on the Web, but, as touched on in the Diagnostics section, popular Web search sites rank near the bottom in the accessibility tests. Several guest speakers to our Comp 190 class echoed this and demonstrated using JAWS how slow and aggravating it is to try to analyze search results and find useful information from currently available search engines. Visually, sites such as Google and Yahoo suffice, but their content arrangement and extraneous information wreak havoc on screen readers.
Complaints about Google
- There is too much content to dig through on the results screen. With each link there is also a incomprehensible description punctuated by ellipses, some page size information, something about cached pages, a category link, and occasionally a relevance meter.
- A lot of extraneous information clutters the page and, when viewed with a screen reader, are processed first before one actually arrives at the search results. This includes information about the number of pages searched, the time the search took, and numerous sponsored links and advertisements. Visually, these bits of data do not get in the way, but they bog down screen readers.
- There are too many links before and after the query box. The user has to tab through at least five links before he gets to the text input, and after this there are more category links before the search results.
- Since there is so much content on the page, it is often to orient one's self on the page. This can be a problem because the user may not know if he is at the 2nd or the 9th search result.
- The tab progression is illogical and inefficient. It takes you down the right side of the screen (the advertisements) before arriving at the content. While there are some business reasons why they do this, it does not seem fair to the non-sighted user.
In response to these complaints, I set out to design a new prototype version of Google and propose some ideas that can be abstracted for search engines in general that may enhance the user experience for visually impaired individuals.
Disclaimer: This simulation does not reflect the opinions of Google.com or any of its affiliates. The graphics and search results used in this demo are for demonstration purposes only and belong to Google.com.
Proposed Solutions
Full redesign with XHTML/CSS. The first step was to re-engineer the existing Google site, give it a slightly improved appearance, and code the entire layout of the search results screen in compliant XHTML and CSS.
User preferences and data hiding. The first of two key features is customizeable user preferences. By using some relatively CSS conventions, the redesigned site can hide content -- both visually and for screen readers -- and thus allow the user to pick what he/she wants to view on the screen. On one extreme, the user can choose to display all the existing content that Google currently displays on its results screen. On the opposite extreme, one can remove everything but the primary link to the search result and the query box.
Embedded "jump links" to facilitate transportation and orientation. The other key feature, as illustrated in the redesigned Google schematic (Powerpoint), are the hidden links and targets that I embedded in the page to help the visually impaired user orient himself and move around on the page. I placed three embedded bookmarks on the page (shown as the red circles) -- one at the query box, one at the top of the search results, and one at the preferences panel. Then, at strategic locations, I placed hidden "jump links" (shown in green) in the form of 1 x 1 transparent GIFs (so the sighted user cannot see them, but the screen reader picks them up and reads the associated <alt> text):
- At the top of the page, there are three jump links that allow you to skip to the respective three target locations. These are the very first things that are encountered on the page, so the blind user can jump around quickly.
- At the end of the preferences panel, there are links back to the query box and the top of the search results. This allows the user to move to other key parts of the page without having to start back at the top or try to tab his/her way through the remainder of the page.
- Following each result link, there is a jump link back to the query box. Thus, once a user has searched and begun reading the search results, he can quickly go back to the query box if he wants to refine his search.
- Finally, following the description of each search result, there is a jump link back to the top of the search results. This simply allows the user to scan more easily without always having to tab backwards or start over from the top of the entire page.
- These embedded jump links can be hidden -- just as with the other different types of data on the screen -- using the preferences menu.
The Prototype: Accessi-Google
So, without further ado, check out the Accessi-Google demo, which is hosted by Ibiblio. The data hiding is accomplished using very simple scripting, which, if coupled with cookies, would allow the user to set his own preferences and persistently use the accessible version of Google in the manner he so chooses.
- Check out the working version
- View XHTML Output
- View PHP backend script
- View the Cascading Style Sheet
Benefits, Tradeoffs, Conclusions
It is hard to understand the benefits of this re-engineered search engine without actually exploring it using a screen-reader. If anything, the site is more visually appealing, and the customizeable preferences make for a better user experience, regardless of disabilities. Other benefits include the following:
- Full XHTML validation under the most stringent criteria (XHTML 1.0 Strict) -- to test, click on the XHTML 1.0 icon at the bottom of the prototype screen.
- Full compliance with WCAG and Section 508.
- Code ratio dropped from 5.15 to 3.68.
In order to pull this off, I had to throw in some items -- namely, the hidden "jump links" -- that some may consider junk that perverts the structural integrity of the HTML document. Again, as with the other prototypes, the site when viewed in non-compliant browsers like Netscape 4- reverts to a black-and-white page that does not look as good as the original Google site -- a fact that would likely prevent Google from adopting such changes for fear of losing those users.
Overall, I think this search engine design is a winner, but there is an inherent flaw. I pulled it off in a day and did not have time to consult with users who are visually impaired. My ideas came from a sound set of assumptions and observations, but this does not mean the result will be useful or easy to understand. By now VI users are probably quite used to navigating treacherous search engines, so convincing them to learn a new system -- even if it were designed with their needs in mind -- would be difficult. Nevertheless, I plan to continue working on it and submitting the proposal to a contact the Comp 190 professor has at Google, who may interested in my work.