To design an alternate version of the Google search engine which is designed specifically to be easy to navigate using JAWS or other such screen readers.
The current layout of Google's page is both difficult to navigate and hard to comprehend using the screen readers presently available to the Visually Impaired. There are many design issues that make using a screen reader on the page challenging, yet many of these are easily repaired with just slight modifications to the design. In addition to verifying that the page follows the web accessibility standards, it is important to remember some of the common complaints about webpages today.
The approach I took to this problem was to try to come up with a page that was both very accessible with screen readers and yet very easy for Google to implement. The idea being that Google could make a few very simple modifications to their search results template, such as adding an additional JavaScript or rearranging the information, which would make all the difference in the world to someone with a screen reader. After talking with some visually impaired web surfers, researching common suggestions for making pages compatible (such as the ones above), and looking into Google's organization, these are two solutions that I am working on:
The basic idea was remove unwanted information, position things in an orderly manner, and limit what appeared on the screen. The first step was to remove all of the information that is usually skipped by a sighted person, such as the time it took to perform the search, how many records were searched, etc. Then the search form was moved to the bottom of the page because after a person has performed a search, they probably don't need to hear what they searched for. This also made the search form easily accessible using the page down function, so that if one wanted to search again before hearing the results they could do so easily. The search buttons were also relabled to make it more clear what their functionallity was and the Google multi-graphic was replaced with just one grapchic requiring only one alt tag. Then the navigation links were placed into one pulldown menu so that they could be accessed if the person desired, but since they probably won't be used, they are hidden within one box and don't all have to be heard. The final challenge was to create a way that the descriptions could be hidden when the search is first performed, since often the title is all that is needed to determine relevance, but displayed if the user so desired.
This presented a hefty challenge, because to do this, the text must be either hidden in the page or inserted into the page without actually having to recreate a new html page. (It would be useless for Google to try to create a new page each time a different description was to be shown). Also, because we are trying to minimize links, a link to show the description would not be very beneficial. Therefore, my approach was to try to make a keyboard or mouse functionality that would cause the description to be inserted into the page. Key events were not practical, because they required the link to already be indicated in some way for the event to occur. Mouse functionality was limited because JAWS doens't provide a 'hover' option and the left button is already used to follow the link. Therefore, I chose to use the right mouse button to indicate that a description is desired. If the user right clicks (which can be keyboard simulated through JAWS) on a link, the description for that link will be inserted.
In the first solution, the functionality works very well, but it requires that google assign variable names to each description and names to each title. This poses a problem because the names are entered manually, not generated randomly, and there is no way of knowing how many search results there will be. Another problem with this solution is that it actually just uses a mouse down event, it does not verify that it was the right mouse, so the description is also displayed when the left button is clicked.
The second solution does verify that the right mouse button was clicked by calling two functions - one to see if it was the right mouse and one to see if it was on the link. THis version allows a little more flexibility in variable names also by importing the message into another function, but the original titles must still be given names, posing a similar problem as the one described above. Also, the insert text method can't be called as a seperate function, it must be used inline with the HTML code.
Obviously neither of these approches are 100% successful. I hope to continue working on this problem to find some hybrid of the two that will be both fully functional and very easy for Google to implement. In an ideal world however, Google would have just one version that would fit the needs of the entire population: the disabled and the temporarily abled alike.