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

[lea_hazel]

I had no idea that screen readers don't accept b and i tags, although I probably should have known, since they've been technically obsolete for ages. Now I have no excuse to slack off. Good thing I'm pretty fixated on closing tags properly, it leaves me less work to adjust.

[cleo]

Wow...

Thank you for this.

Very nice primer!

[aris_tgd]

The only thing I'd add is that the "title" attribute can be used in most tags to give you a "tooltip"-like hovering text box. Even a span tag (try hovering over this sentence.) So in <img /> tags, the "alt" attribute should be used for text that displays when the image is not rendered, and use the "title" attribute for extra information about the image.

[schemingreader]

Very helpful, thank you!

[acchikocchi]

!! Thank you so much! I'd never heard of... almost any of the tips/tricks in this post, actually. I'll be working on making these tags a reflex pronto. :)

[rydra_wong]

Thank you so much for writing this -- bookmarking.

Via Metafandom

[ten]

Although I'm a huge friend of accessibility (one of the main reasons I support Dreamwidth heartily) I didn't know about the i and be tags yet. Thank you!

[azurelunatic]

If you want all the text in your journal to be spiffy red, this should NOT be done by making all the text in each entry red. Instead, you should tweak your journal's style to make the text the color you want it.

Changing the color of the text in your entries is about the second-rudest thing you can do with markup. This is because it will be displaying on the reading/friends pages of everyone who reads you. You do not know what their background color is. You don't know what level of contrast they can read. You don't know what color gives them an instant migraine. Unless there's a need to turn certain small chunks of text a specified color (and specify their background too) don't do it.

The rudest thing is split between specifying colors in a community entry, or specifying colors (without actual need) in comments in someone else's journal.

[bravenewcentury]

Here via metafandom- thanks so much for this. I had never even thought about how screenreaders would interpret HTML tags before *facepalm*. Memming for future reference.

[kyoutenshi]

Thanks a lot for this. I'd never even heard of the < p > and < li > functions before, and now I'm wondering if there's a list somewhere with all the different piece of code that can be used in a Dreamwidth post.

[exhausted_pigeon]

Thank you for posting this. I never knew that using i and b could cause so many problems.

[mllesatine]

Oh, wow! I had no idea that there even is a way to make my journal accessibility friendly. Will use it from now on.

via metafandom

[falena]

Thank you for this. I had no idea I could make my posts more accessible for people with disabilities with so little effort on my part.

[dancing_serpent]

Here via bethbethbeth. Very useful entry, thank you, will add it to my bookmarks.

[siljamus]

*mems*

Thank you for this - very informative and a good reminder of why it's important to take the time.

[misscake]

Great post! I will definitely memory this and refer to it often!

[queenbarwench]

Thanks for the link to the accessibility guidelines. I went looking for those myself a while back, but my google-fu failed me that day.

[saffronhouse]

This is just fantastic! Such helpful advice for the wish-we-were-more-geeky-than-we-actually-are folks. Thank you!

[valentinite]

Thanks for a nice writeup of this -- I know all of it, since I've done software accessibility work, but I couldn't have said it nearly so concisely and eloquently.

I'd also add that if you want to use tables for formatting, there's some easy ways to make sure they look and sound good with the formatting gone -- I do have some tables on RP journal userinfo pages because it's just What Everyone Does. But I pull them up in the Lynx browser (which is text-only) and make sure that everything is in order and comprehensible. No, they're not ideal, but we can't use CSS in userinfo pages, so making the tables non-sucky is a compromise.

[worldstosee]

Cool post. one note on the title attribute - if the link text is descriptive enough you really don't need to add an extra one. Adding it when it's not needed just makes reading the link longer for screen readers. It's actually better to use descriptive link text rather than resorting to the title attribute.

Also I'd mention you don't need alt text if the image is purely decorative - like having alt text for rounded corner images would be silly - but I've seen people assume it's needed.

Awesome on the valid code info - I wish dreamwidth did a better job with it!

[lady_ganesh]

Cool! I knew people were gravitating toward 'em' and 'strong,' but I didn't realize it helped people using screenreaders.

[dame_grise]

Umm... I was taught in formal coding classes to code in uppercase. I don't always, but that's the standard I was taught and try to conform to.

Metafandom

[ranrata]

Well, I've been learning a lot since joining Dreamwidth. Bookmarking, and will try to keep this in mind.

[emceeaich]

I've hand-coded markup for years out of a compulsion to be correct. Thank you for reminding me that there is a good reason for doing so.