Current mood:	nerdy
Entry tags:	geek, geek: coding

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.)