Nerdy PSA: Accessibility tips for the casual coder

[hope]

Most people know enough quick-and-dirty html to give their LJ posts a wee bit more formatting without having to work in the dreaded Rich Text Format.

But DID YOU KNOW that there's a right way and a wrong way to use these wee bits of formatting and functionality?

The main one I see most often is using <i> </i> for italics and <b> </b> for bold.

Yes, this will visually represent italics and bold in pretty much all browsers, but if you want to be accessibility friendly, you should:

use <em> </em> for italics, and
use <strong> </strong> for bold.

Visually, the result doesn't look any different - italics and bold! - however, the accessibility point here is that not everyone 'reads' information on web pages the same way (with their eyes on a screen displaying a browser). The 'em' and 'strong' tags are accessible to other technology such as screen readers, which provide an audio verbalisation of what is being displayed on the user's screen.

The screenreader technology interprets 'em' and 'strong' as requiring emphasis, and delivers them thus. It will not recognise 'i' and 'b', therefore not translating that bit of formatting to the user who is not accessing your post visually.

It may seem like a drag at first (I have to type 'strong' instead of just 'b'?? oh, man!), but really, you get used to it very fast with the added bonus of being a good netizen. After all, you *do* want more people reading your post/blog/story, right? Frankly, this way is just as quick-and-dirty, once you get in the habit of it.


Here are a few other tips for making your usual quick-and-dirty markup a bit more accessible. There is a lot more than I've listed here, but these are the ones I think come up most in your average blogger's usage, with the most important at the top.

• Use 'alt' tags on your images.
  
  Know how sometimes when you mouseover an image a little flag with some text shows up? This is an alt tag. This text should provide a brief description of what the image is, again for the benefit of people with screen readers. They can't *see* the image, so the reader will tell them what it is using the text from your alt tag. This is especially important if you're using an image as a link - if the user can't see it, how are they going to even know it's a link or important part of the navigation? WITH THE ALT TAG, THAT'S HOW!
  
  alt tags just go into your img code, thus:
  <img src="http://www.url.com/yourimage.jpg" alt="A description of the image" />
  
  Note for Dreamwidth users: The "Description" field you see when managing icons is for text that will go into the alt tag of that icon.


• Use 'title' tags on your hyperlinks (text links), or at least make sure the linked text is descriptive in itself.
  
  Similar to the alt tag for images is the title tag for links. Again, the way particular screen readers navigate the page for the user, title tags (which appear when you mouseover a text link) give the user more information, helping them to navigate the page.
  
  For example: Super-wiki
  
  Looks like:
  <a href="http://supernaturalwiki.com" title="Supernatural Wiki home page">Super-wiki</a>
  
  If you're too lazy to put a title tag in each hyperlink (as I generally am), at the very least you should make sure that the text that's being hyperlinked is descriptive in itself.
  
  For example, don't do this: Click here to go to the Super-wiki.
  
  do this: Go to the Super-wiki.
  
  Screen readers can tab from link to link on a page; reading out 'here' as a link is not very helpful to the user trying to navigate, whereas 'go to the super-wiki' is.
  
  ADDENDUM: The priority here is to make sure the text that's being hyperlinked is descriptive. Only use the 'title' tag if this is not possible, for whatever reason. It's better to simply have descriptive linked text instead of descriptive and titled.
  


• Write valid code
  
  This one is good when you consider not just that some of your readers may be using assistive technology, but the fact that not everyone else is accessing your site using the latest version of Firefox on their Windows XP machine on broadband. In other words, the software and hardware may vary wildly from user to user, and you want to make sure that the coding you're doing has the same end result for everyone.
  
  Luckily there's a handy tool out there for responsible coders who want to make sure their code is 'valid' - that it not just looks fine to you, but will work across platforms and a not cause any problems: the W3C validator.
  
  The main two things easily tackleable that I can think of are:
  
  Always code in lowercase: <img src="etc" />, not <IMG SRC="etc" />
  
  Always close your tags.
  This one is obvious in the case of formatting and links, but it does actually apply to image tags, bullet points, and (if you're coding off lj) line and paragraph breaks.
  
  Paragraphs should be enclosed in <p> (start of para) and </p> (end of para).
  
  Each bullet point should start with <li> and end with </li>.
  
  Line breaks and image tags are self-closing tags. You may have noticed in the examples above that I left a / before the > at the end of the image tag. This is how it self-closes. The line break tag, which you may be familiar with as <br> should actually self-close as this: <br />
  
  NOTE: LJ automatically inserts valid paragraph and line breaks. You don't need to use <br /> or <p></p> on LJ. This is still good to know if you're coding your own website, though.


• If doing something fancy, don't co-opt code made for another function; use the code made specifically for what you want to do. Even if that means you have to do some research and LEARN something new!
  
  Examples:
  
  - HTML tables are made for displaying data. For a page layout you generally should be using CSS. See the WCAG for how to make sure your data tables are used effectively, or just how to use them properly if you're determined to use them for layout.
  
  - Title tags are for links. If you want a mouseover message to show on text, don't trick the screenreaders by creating a dead link; use something like the acronym or abbreviation markup.

More info on all of the above can be found via the HTML Techniques for Web Content Accessibility Guidelines 1.0. If that's too intimidating to tackle, you might find some of the W3C's tutorials useful.

Alternatively, ask - your flist or someone who you think might know the answer. I don't mind being asked! Having read the WCAG myself, I am happy to put it to more use than just my own coding :D


And another note, because I know someone will ask! To display < and > instead of rendering the tags they're used in, I used the HTML symbol codes for them:

&lt; = <
&gt; = >

And yep, I used the ampersand symbol html code (&amp;) to *not* render the above html codes.

You can always find handy html symbols by just googling it. You're probably already familiar with &hearts;


Addendums to this post following comments

Using strike tags

Strikethrough tags (<s></s> & <strike></strike>) are technically not accessibility-friendly at all. Screen readers will not render it and it's possible the W3C validator won't validate with it in play. If the effect of the strike tag is intended to be solely visual, it's recommended you use CSS to display it as struck through.

The alternative to the strike tag is the del tag (<del></del>). It's purpose is to indicate changes made to the webpage - text that has been deleted from the document on display.

I think it's pretty reasonable to say that struckthrough text is a bit of coding that's been hijacked from its original use for fandom's lexicon. Your page may not validate if you use strike - it will technically validate if you use del - but in terms of making it screenreader friendly, I think your intentions will be missed on it regardless as it's quite a visual way of communicating your point.

I believe that screenreaders will still read out the text as if it wasn't struck through, though, so you're probably not causing any technical problems (just possible confusion of the user) by continuing to use it.

(Sources: Webdesignfromscratch.com, HTML Quick.com, W3C)


*Asterisks* and other ways of using punctuation to convey emphasis instead of code

Again, this seems largely a visual thing; and again, see above with regards to hijacking asterisks etc to convey actions rather than formatting.

According to Web Accessibility In Mind (WebAIM),

Screen readers read most punctuation by default, such as parentheses, dashes, asterisks, and so on, but not all screen readers choose to read the same pieces of punctuation. Some do not read asterisks by default, for example. Periods, commas, and colons are usually not read out loud, but screen readers generally pause after each. Users can set their preferences so that screen readers read every punctuation mark and character.

So the answer is: screen readers might read your action, *shrugs* as: "star shrugs star", "asterisk shrugs asterisk" or "shrugs".



A note on intended use of this PSA

This post does not set out to explore and explain the ins and outs of accessibility for people building websites from scratch. There are a range of resources on the web out there that'll do that for you.

My intention with this post is to provide a few easily-understood tips for people posting to services like LJ and Dreamwidth, who would like to know more about how to make their posts accessible, but don't necessarily have the technical confidence or knowledge to dive into the world of coding tutorials on the web.

Please be aware that the guidelines described above do not encompass the extent of accessible use for the tags - for example, use of the 'alt' tag in images can differ a lot depending on what the image is being used for. I've not gone into it here because I'm writing with the idea that the people reading will be solely using the img tag to post pictures to their blogs, rather than building websites that use graphics.

If you're serious about accessibility and are writing your own code off LJ/Dth, I strongly recommend reading up on more accessibility guides. The W3C is the hub for this; if you find it too dry or hard to get into, just google "accessible code" and browse through the results.



Feel free to correct me if any of the above needs correcting, or suggest any more tips I should have included. (With the understanding that I've tried to go with layman's terms here, for people without geeky motivators or expertise.)

Comments

[scemo]

Oh, this is splendid. Thank you!

Would you happen to know whether there's a difference between using <s> and <strike> ?

[dragonfly]

Bookmarking! Thank you.

[jetsilver]

Thank you for this. Bookmarking and I will make sure I retrain myself.

[pseudo_tsuga]

Thanks so much for all the info!

[omgaeula]

So informative! I had no idea what is meant to make websites accessibility friendly before your post. Thank you!

Here via Metafandom

[gaycrow.livejournal.com]

Thanks for this.

I have a question: are speech quotation marks necessary when using html coding? (Is this a silly question? ;-) ). I'm self taught, and originally put them in religiously, but then noticed that html writing seems to work without them. It saves a fair bit of time not using them, but is it better to keep them in?

Here's an example to make my question clearer.

[img src="http://www.url.com/yourimage.jpg" alt="A description of the image" /]

See those little " in there? They're what I'm wondering about.

[shina]

Thank you so much for this post. I've committed most (if not all) of these mistakes and will try to remember to correct them in the future!

[helens78]

Found this via elke_tanzer, and I've memoried it -- this is all really nice stuff, and it's something I want to overhaul my actual website to do for sure.

[sinatra]

thanks so much for this!

I didn't realize about the bold and italics, and I had always wondered how to do alt tags. (I'd have Googled it if I had known what they were called, haha)

[nostariel]

Yay for accessible coding!

One note: em isn't really a replacement for italics, they're semantically quite different (as are b and strong, obvs.). For example, I see many people put the titles of shows, films, or books in italics, and if they changed that to em it would be totally wrong, unless they felt the need to emphasize the title for some reason. I think <span style="font-style: italic"></span> would work fine for those cases, although I've seen arguments in favor of using cite, which is what I like to do.

[david adam &lt;zanchey&gt; (from livejournal.com)]

Wandered over here from another LJ, and had an discussion about the things you've recommended. I'm not trying to detract from the advice you've given, but perhaps I could offer some refinements.

The >b</>strong< dichotomy is an interesting one, for two reasons: it may not actually make a difference because screen readers at least in 2008 tests didn't use the strong and em tags anyway (http://www.paciellogroup.com/blog/?p=41), and I'd argue that any user-agent which follows the specification to the extent of differentiating between b tag and the strong tag is living in a dream world of candy and fairies where all HTML validates, etc. etc. In other words, if you're writing a screen reader that ignores b tags and only emphasises strong tags in its default settings then I'd say you've done your users a disservice. As a result of these two things, I tend to use the shorter forms anyway.

From an information architecture standpoint - good lord, I've only known that term for six months and already I'm waving it around like a plonker - providing descriptive link text is infinitely better than the title attribute. http://www.rnib.org.uk/wacblog/articles/too-much-accessibility/too-much-accessibility-title-attributes/ is someone else's rant on the topic.

An excellent further reference (in my experience) for your readers is http://diveintoaccessibility.org/

[sophie]

Saw this from a link in a comment elsewhere on DW - thanks for this! :)

I actually do want to ask one thing, though. Does self-closing a tag like <img /> actually help in a non-XHTML context? The thing is, the slash to end a self-closing tag isn't actually valid under HTML, only under XHTML - and Dreamwidth doesn't actually serve any XHTML. (In fact, according to the HTML spec, using '<img />' in code should actually render the same as '<img>&gt;' would, because of what's known as SHORTTAG support. However, no browser actually implements this part of the HTML spec because it would break the Web entirely.)

So I'm kind of curious to know whether it does, in this case, help.

[trouble]

Hi Hope!

I'm going to be linking this on disability sometime in the next few days, because I think it's a useful resource.

But one thing I would have done differently is title your post something that made it clear what your post was about. :)

[jadelennox]

this is a great resource! The couple of points, though. Most screen readers don't actually handle the title tag at all, although they can be configured to, and in general title tags (except in forms, where they are actually useful) encourage people to put descriptive information in places where they are invisible to people who don't use keyboards and to people with out-of-the-box screenreader configuration. (I did see your addendum, but the fact is that title tags on links are invisible to most screen reader users and all keyboard-only users, so I actually encourage people to avoid them for accessibility purposes.)

Also, while I am strongly in favor of semantic coding, most screen readers deal with italics/bold exactly the same way they deal with strong/emphasis. Although it is still important to do the semantic coding!

[jadelennox]

I think my top four list of things that people who are making blog posts should know are:

1. What you said about descriptive link text. The importance of descriptive link text is huge.
2. Trying to be clever with link names, style text, etc., can make your page less accessible.
3. When you are making interesting layouts (less likely on a blog post, although you might do it on a style), use CSS instead of tables to lay things out. Really. I know people disbelieve that it matters but it really really does.
4. If you are conveying any information solely via color, formatting, image, or flash, make sure there is an alternative way of getting that information. If you are conveying navigation solely through one of those methods, make sure there is an alternative way to navigate.

[starwatcher]

.
I know I'm very late posting, but I hope you can answer a question.

I understand <em> and <strong> instead of <i> and <b>; the former provide spoken emphasis for the listener.

But there are times when I want a visual emphasis -- say, bold for a section heading, or italics for a book title -- but it would sound 'off' if there was spoken emphasis. I wouldn't want a screen reader to be 'shouting' a section heading, or giving spoken emphasis to a book title.

So, is it valid to use <em> and <strong> when I want spoken emphasis, and <i> and <b> when I want only visual emphasis? I've listened to books on tape; such things as section headings and book titles are understood in context, without a major vocal change.

Or is there some commonly-used alternative that I need to learn?

What about section breaks? Does a screen reader make note of a standard <hr>? Or is there something more efficient? Should I put in a <hr> for visual readers, along with a visually 'hidden' (same font color, same background color) notation of 'scene break' for a screen reader to speak aloud?

Thanks for any help. I'm starting a new fic-journal on DW, and I'd like to make the stories screen-reader accessible as much as possible.
.

[lightgetsin]

This may have already been said, but some of what you say is not actually true. E.g. my screenreader renders i, b, and strike tages just fine, because I told it to. You're not wrong that out-of-the-box these things are not accessible, but I think it's important to clarify that this is coding for the lowest common denominator user who hasn't done the most basic settings tinkering, and also these rendering default patterns are likely to change in the future.

[st_aurafina]

Thank you for this link - I already knew that em and strong were better for older screen readers and had started using them, but the rest was a bit beyond my knowledge. You explained it all really clearly, it's going to be easy to implement!