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
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
