[uf-discuss] Hyperlink Include Pattern Research

[Ben Ward]

Last year I found some time to edit the include-pattern pages on the  
wiki in response to serious implementation issues surrounding the use  
of OBJECT to reference other parts of the page (aside: It causes  
multiple HTTP requests to same URL in some browsers and nearly  
blocked the inclusion of microformats in one of our sites).

One of the key edits was to move the hyperlink-based alternative  
include pattern above OBJECT, and recommend it in its place. At the  
time of my original edit, I ensured that all hyperlink examples  
included inner-text to best support accessibility, according to my  
understanding of hyperlink issues at the time.

Since then it was raised that hResume actually required that _no_  
inner text be present (regardless of the include technique used) as  
it was only used to include a single piece of information (the hcard  
fn property). This resulted in an edit — still present in the current  
page — that recommends a hyperlink with no inner text, but including  
a title attribute in its place. The whole development has become  
fuzzy and lacks evidence to support mark-up decisions either for or  
against support of certain accessibility techniques.

The issue has been short on solid research, so thanks to the  
commitment and incredibly dedicated work of Mike Davies, my co-worker  
at Yahoo! in London, we now have some.

Mike has organised a test of hyperlinks in multiple configurations  
and had them tested by real users of screen readers (Artur Ortega and  
Victor Tsaran of the Yahoo! Accessibility Stakeholders Group).  
There's no simulation, or guesswork. Both testers depend on screen  
reader technology every day. With their co-operation, we hope to have  
produced the most useful and insightful test data on hyperlinks, and  
identify the most probably behaviour of most screen readers in the wild.

Mike has provided a thorough write up of his research on the Yahoo!  
User Interface Blog: http://yuiblog.com/blog/2008/01/23/empty-links/

I encourage you to take a little time to digest it, and note the  
complex caveats that screen readers introduce to our work. The  
conclusions are drawn clearly, and there's plenty of reference to our  
include-pattern development.

I need to do another pass over the include-pattern page, tidy it up  
again and move discussion onto the -issues page (I didn't have a  
chance to update the issues page when I updated the spec, so I'll do  
that this time around). I'll be taking some time to digest this  
research first, and work to present the pros/cons of our current  
solutions as best we can. In doing so, I'll try to identify if there  
are situations which neither pattern can solve.

Your feedback is encouraged, and we hope this research proves useful  
to the community (and beyond).

Regards,

Ben