Fixing the ‘read more’ problem
Written December 21, 2009. 19 comments.
In my continuing journey to be as anal as humanly possible regarding web standards, I thought it about time to look at one of my pet peeves – the ‘read more’ link, also commonly known as ‘more info’ and sometimes ‘keep reading’.
There’s nothing wrong with this practice and in fact it it’s an ideal way of fitting points of interest on a single page, especially when you need to preview a lot of content. But my only qualm is with the traditional implementation of such links (I’m a big offender from way back, but I’m making an effort to change!).
The problem is that ‘read more’ by itself is meaningless to a search engine and a screen reader. A site map of a typical homepage for our imaginary company below – let’s call them CompanyX – which contains ‘read more’ links would look like this:
Looks strange, doesn’t it? When a search engine spider examines your links, all those ‘read more’ links don’t really help describe what they’re about. And for those relying on screen readers, imagine how it sounds when that site map is read aloud. Not very useful is it?
The good news is it’s very easy to rectify and it won’t interfere with your design. Here’s how.
<a href="">Read more <span>about CompanyX policies</span></a>Now all you need to do is hide the span with a little CSS in your style sheet:
span { text-indent:-9999em; position:absolute }So now your site map will look like this:
- Home
- About us
- Read more about CompanyX policies
- Read more about CompanyX staff
- Read more about the CompanyX mission
- Our services
- Read more about CompanyX services
- Contact
In one very simple step you’ve managed satisfy accessibility considerations and help improve the quality of your site map.
Too easy.
Start of pageWho is That Web Guy?
Michael is a veteran web designer / developer / usability evangelist, practitioner of W3C guidelines, and currently head of the web dev unit at Stormbox, a branding and creative communications agency located in Perth, Western Australia.
Another alternative is to customise the ‘read more’ text for each article. WordPress and others have plugins to make this super easy. If you’re using modx a custom field will sort you out.
You could simply set up your blog to display “read more about [blog post title]“. I usually advocate front-loading the key terms but I’ve not seen adverse results from this approach.
Nice reminder.
One of the points of expanding the semantic nature of the “Read More” text is to give it context for all readers.
People with the ability to scan the entire page (thats most of us) will have no issue in determining what the read more link is for. That’s a given, one of the reasons they work and test so well – sadly. Yeah it is a sad fact that people do respond to “read more”, “click here” and the like very well in testing.
However it all falls apart with anyone with a visual disability from screen zooming to screen readers. Here you need to know what the link is about. The more semantic information for the link the better.
Hence I would recommend against using display:none. In favour of moving the to be hidden text to the left off the visual screen.
Still better to have to full semantic meaning of the link. But business reality doesn’t often allow for this.
That’s something I’ve always wondered but can never find a clear answer on. I could understand a problem if display:none was used inline, but in an external style sheet is there still an issue?
Using the text-indent method would have the same effect unless I’m mistaken.
Any property works the same, no matter where you reference it from, be that inline, embedded in the page or externally linked.
Display:none will appear to you and me to just remove the element. What it in fact does its more than just remove a visual display. The element is forced to not generate a box at all. Also any children can’t generate a box. So it removes the element and its descendants from the scope of the readable DOM. Hence a search engine will not see a display:none element. And as extensive testing has shown the same goes for screen readers or even page reading software.
Hence it is established practice not to use display:none on small runs of text that you want a search engine to see, but want hidden to the general able bodied public.
However there are good cases to use display:none. Like large menu systems.
The text-indent property just moves the element off the visual page, but still on the virtual page. So it is readable as the box of the element has not been forced to collapse.
Strange I didn’t think of text-indent considering I use it everywhere else.
Some braille readers tend to only read the page as it is presented, as raw semantic data. As did some of the older screen readers.
However current screen readers (like Jaws) are attached to a browser. What the they see (read) is what the browser outputs, So this includes javascript manipulation of style or content, css content inserts, and in this case removal.
Some screen readers also process the Aural media types and the related properties. However this is limited.
If an element doesn’t have a box generated (see my previous comment) the reader can see then it will just ignore it as a non informational, visual only, element.
Yes you can screen readers can use javascript too.
You need to lift the element outside of the visual document flow.
feel free to delete this comment.
All fixed now.
Thanks for the help Gary.
Keep these good ideas flowing. We watch with interest!
Stanze.
@Angelina: That’s perfectly acceptable and I do it sometimes for the exact same reasons.
web design company melbourne
http://www.googleseoservices.com.au/webdesign.html