Recently in Accessibility Category

Right now I'm archiving some Teaching with Technology portfolios, which are online teaching portfolios created by Penn State graduate students, and every semester I face the same conundrum.

On the one hand, we want to make the process of creating a Web based portfolio as easy as possible. Which means we allow WYSIWYG get editors. With these tools the students create some very appealing, well-designed sites and home pages. So far so good.

But then I deconstruct some of these for archival purposes (that is, students give us permission to take their pages and move them somewhere else so they can be preserved in an archive). This is when I get to deconstruct some of these sites and realize that the lovely designs are courtesy of some outrageously clunky code generated by some prominent HTML editors (hint - it's not Dreamweaver, but products some other company whose name begins with an M). Depending on what was on the site in the future, these instructors could be receiving a letter from the Office of Disbality services in the future - some of them are that bad on the back end.

Of course it's not really the instructor's fault because they're only doing what the HTML Editors let them do. If I didn't know any better, that's what I would be doing as well...But the problem is that we are encouraging instructors to develop content for the Web, but at the same time trying to train Web developers in accessibility, and sometimes accessibility is tricky and technical.

What's the ultimate solution? Surely better tools are the answer, but then you face a complexity problem. Probably the best WYSIWYG editor for accessibility, Dreamweaver, is actually the most complex tool to use (not hideously so, but enough to discourage some users). Unless instructors want to create "professional level" sites, they may not be willing invest the training time.

And no matter what tool we use...there will be training needed to achieve optimal accessibility. Even a simple, but standards compliant platform like Movable Type or Drupal requires some knowledgable CSS tweaks every now and again (not to mention remembering to give a title to all your uploaded images so an ALT code is generated).

In the meantime, I'm in an interesting quandary as both a portfolio facilitator and accessibility guru. How much accessibility and usability can I insist upon before the Web creation process becomes too burdensome? I doubt it will be enough for full Section 508 compliance. Even worse - how much time can I spend fixing the wretched WYSIWYG code? Accessibility retrofit is such a pain.

As many regular blog readers know, I'm still a big fan of Dreamweaver even in this brave new Web 2.0 world. But shouldn't I be exploring the new content management systems like Drupal and Movable Type...or even ANGEL?

Actually I have been, but I'm also finding that Dreamweaver has been an indispensable partner, especially for complex CMS pages - because Dreamweaver is the most flexible tool which still generates the cleanest, most accessible XHTML around.

If you can figure out how to cut and paste HTML (and what respectable Web master can't do that?), then Dreamweaver can still be a great time saver.

Here's a mini-tour of some useful Dreameweaver tools and how they've been helping me streamline a Drupal or Movable Type page.

Insert Headers

Long pages should have subheaders (e.g. H2,H3,H4) - even those in a CMS...but amazingly few editors I've encountered recognize this fact. They'll let you shrink and enlarge text or change colors...but they won't let you actually insert a correct level of header (unless you know the tag).

Dreamweaver not only lets you do that, but gives you a keyboard command - sweet.

Image Insertion & ALT Tags

Ever since Dreamweaver MX 2004, the software has been enabled with a key primal instinct. If you insert a picture - it asks for an ALT tag. You have to be pretty lazy to ignore it. Plus Dreamweaver captures the image size and image file name.

It's true, you can't just cut and paste the code into Drupal or Movable Type and expect an image to appear...but will have a record of the file name, ALT tag and size attributes. All you, the Webmaster, have to do is upload the images into Drupal and change the SRC path (which is always the same). You won't have to fill in the sizes or guess on the file name. And if you miss an image...the ALT Tag has been pre-filled in for you.

Data Tables

One school of thought says to avoid them, but sometimes they really are the best way to present data (see below). But few CMS WYSIWYG tools include good table tools, and even fewer let you set the SCOPE attribute.

 

In Dreamweaver, inserting the table prompts you to select a table layout with table headers (and the right SCOPE). If you get the initial set-up correct, your accessibility issues have been mostly solved. And if you need to tweak the table, Dreamweaver can do that too.

A Break is a P and not a Break

A basic accessibility mantra is to make sure that paragraphs are chunked into P tags and groups of sentences separated by BR tags. That is, blank lines between paragraphs should be caused by the P tag and not two BR tags. This allows screen readers to re-read single paragraphs as necessary. If it's all BR tags, then the HTML is just one giant text block structurally. Some HTML editors ensure that blank spaces between paragraphs really correspond to the P tag, but more than a few don't...

Bold or Strong

Want the bold command to be B or STRONG? Dreamweaver lets you choose either by default (and you can even activate commands to do both if you're really clever). The one thing you won't have to do is manually type in "<strong>" all the time - that one gets old very fast. Nor will Dreamweaver generate one of the scariest pieces of CMS code I ever did see - <span style="font-weight:bold">. This may validate, but if you're going the presentation route, surely <b> would save many bytes.

And it gives a Local Backup

Penn State is pretty good about backing up server files, but glitches do occur (sometimes I push the Delete button when I shouldn't), but Dreamweaver allows you to archive key content...if you're feeling paranoid.

Same Toolset for the Same HTML

As much as I like the concept of CMS, I've been exposed to enough of them that I'm starting to get a little disoriented. It really is nice to have one HTML generator that is independent of everything else. And if the HTML editor isn't working on a Mac (or IE 7) today, then Dreamweaver will come to the rescue

Any Drawbacks?

The two I can think of are that 1) Dreamweaver costs money and 2) Dreamweaver is complex for a WYSIWYG editor. Plus, you usually have to set your CMS HTML editor to view tags only when it comes time to cut and copy code (but you can ususally toggle back to WYSIWYG mode).

But if you are a Web saavy user and already have access to Dreamweaver and spent all that time getting up to speed in it, I would think it would make sense to leverage the tool.

This entry composed in Dreamweaver and pasted into Movable Type - with subheaders.

This is inspired by a fight I was having with a content management system trying to create a properly accessible data table.

Those of us who follow Web standards and accessibility have heard the mantra that layout tables are bad. Those would be the ones with the colored sidebars and top menus that designers created to add some formatting order to the chaos of the original vanilla Web site. FYI - the problem with layout tables was NOT usability but screen reader glitches (which were bad) and slower load times because table code is pretty chunky

But...that does not mean all tables are bad. The HTML table tags were originally designed to present tabular data much like Excel does. And guess what, the TABLE is still the best tool for that job. Especially if you add properly tagged headers (TH and CAPTION) and use style sheets for formatting.

By now though the mantra that "tables are evil" is so exagerrated that many modern tools have lousy support for tables. In many cases, you  have to manually insert the HTML because the WYSIWYG tools have no table options.

To add insult to injury, some systems don't know what to do with TH and CAPTION. I had a perfectly well-formed data table (thanks to my personal friend Dreamweaver), but when I copied the code over, the borders for the TH cells look really really weird.

What did I do? You  guessed it - I changed the TH  cells to TD cells because I didn't have enough time to fix the CSS (maybe next week). I like my Web 2.0, but I don't want them to get in the way of my accessibility fixes!

One the earlier accessibility mantras was to put content before navigation. The theory was that that screen reader users found reading the same main menu options on each page to be distracting and time-consuming.

Yet visual users generally prefer navigation menus to the left (which means they usually come first in the code). Interestingly readers of right-to-left scripts like Hebrew and Arabic want their navigation to be to the RIGHT (where their eyes first hit when reading).

In any event, some experts advocating placing navigation on the right so that content would come first in screen readers. Another variation was to put navigation after content in the HTML, but use CSS to move the navigation in the top/left where visual users were expecting. The final solution was to keep navigation first, but implement a "Skip Main Menu" strategy. Ironically, I found a Usability Source Order Survey in Australia which supports the "Skip Main Menu strategy" as the best choice.

According to this survey, it's not just visual users who expect navigation, but many screen reader users as well. What many users really wanted a quick bypass once they got familiar with it, but they were still expecting it to be there first.

I would compare to previews on a DVD. I expect the previews to come before the main feature movie, but am grateful when I can skip them (especially if the DVD is due back at the store before midnight). On the other hand, if the previews come AFTER the movie credits, I will be a bit confused (especially if I'm expecting the DVD bonus interview features next).

This is kind of a relief from a developer point of view because you can really use the same code for everyone with an extra tweak (actually, a lot of people would like "Skip Main Menu" - including keyboard users). Many visual users do prefer left hand or top navigation over right and bottom, so using right/bottom navigation seems awkward. I'm also glad to be avoiding CSS floating hacks which move content out of their source order. I've always thought this was dangerous, because other users (e.g. low vision users or color blind users) use alternate CSS sheets. The more you keep the content flow the same across alternate styles, the more accessible you are.

I was in a meeting yesterday with Bill Welsh of the Office for Disability Services along with Christian Vinten-Johansen, Dave and Wendy to discuss accessibility of new technologies including blogs.

How accessible were the blogs? Fairly accessibile, but with some quirks.

POSITIVES
* Movable Type incorporates comprehensible ALT Tags for image icons
* Movable Type generates well structured XHTML which makes it easier for screen reader users to navigate a blog posting
* Tabbed browsing is enabled, even in the side buttons (you have to keep tabbing though)
* Entry forms fields were generally well labelled for screen reader access
* Color contrast is generally good from the entry side. Color variation in post themes are more variable, but good contrast themes are available

GOTCHAS
The big gotcha was all the embedded Javascript included in the code. It's not clear how a screen reader would be able to handle all of it.

A visually impaired user could likely read a blog and probably add comments, but could they post to their own blog without help? We will see.

COURSE ALTERNATIVES
If a course is requiring the use of blogs for a course, it may be the case that you would need to allow for alternate technologies such as an ANGEL Discussion Forum or e-mail for some users.

In some cases, a saavy visually impaired user could post their own entries in static Web pages (I used to do that myself in a 'pseudo-blog')

We all have our favorite Web 2.0 apps (even cynical old me), but it cannot be denied that any new Internet technology must inevitably be followed by accessibility issues. That's just part of the new Internet cycle.

Fortunately, this is often followed by accessibility tools and recommendations.

Some Web 2.0 Pitfalls

1. Where's the ALT Tag? - If you upload an image via a Web form and you don't have a chance to give it a title or description...you've probably uploaded an image with no ALT tag.
2. Where's the Podcast transcript? - Just because it has a cool name, doesn't mean it's not an audio file which needs to be accessible to hearing impaired audiences.
3. What did AJAX do the screen? - When an AJAX app like Basecamp puts a new message on the screen, your eyes will catch it. The screen reader, on the other hand, might miss it...
4. How good is that code? - Some WSYWIG editors generate better structured code than others. You want to avoid ad hoc styles and breaks and go for headers and paragraph breaks. And if you're persnickety like me, you probably want access to the RAW code so you can fix it!
5. Same Link Text - Some apps include multiple links with the same text (e.g. multiple "Read More" links which is not recommended). It's preferable for links to have unique text if possible...but it is more difficult to implement in the backend.
6. Web 2.0 = scripts! - Scripted pages can be made accessible, but you do have to work at it

Some Good Examples

Some Web 2.0 developers HAVE thought about this already. For instance:

• The Web editor for Wikipedia does convert its Wiki syntax to well-structured XHTML.
• Both Movable Type and Drupal uses CSS to make Headers appear to be hot-looking page titles and sidebar widgets.
• Movable Type will also put in an ALT Tag for any uploaded image...but it will match the title of the image unless the saavy blog writer changes it. Drupal will also allow to edit in ALT tags...but have to be on the saavy side for this one also.

At the same time, there are new standards being developed...such as WAI-ARIA.

The gotcha for these is that you may implement them, but an old screen reader might still miss them...

Accessibility is another scary word for many people, often associated with high costs and strange tags. But having worked with it the past few years, I think the real problem isn't making your products accessible in the beginning. The real problem is RETROFITTING it.

I've had to retrofit accessibility, and I know what a colossal, time-consuming pain it is. But if you build it from scratch, it's almost seamless - just a matter of adding some descriptions at the right time. Here are two examples of how can spare yourself some grief by adding in accessibility up front.

ALT TAG

The ALT TAG (or attribute) is the code that describes your image in words for a screen reader. It's also what appears if your image doesn't download correctly (so non-screen readers can benefit from this tag as well).

If you retrofit, you have find all your images on all your pages and insert ALT tags. If you have a large Website, you will be spending a lot of time hunting, updating and maybe even asking "what is this anyway?" You probably will be looking at the HTML code to match images and alt tags. It will take several hours if not days to do it all. There will be cursing involved.

If you do it from scratch, you just add an ALT tag every time you insert an image. If you use Dreamweaver or other accessible aware development system, it even prompts you for an ALT tag when you insert an image! It's just an other 30 seconds per image, and you usually remember what text to add.

The same is true for creating accessible tables and forms. Adding the correct tags at the beginning during development is much less of a burden than putting them all in later.

TRANSCRIPTS

Great audio will usually require a great transcript or caption. And some people (like me) may actually prefer the transcript if 1) their audio is buggy or 2) they read faster than they listen. There are some tricks to getting one without hiring a part-time temp.

The key is to write out what you want to say beforehand. If you're doing a solo podcast, voice-over, role play or audio for a Powerpoint, you can save yourself a lot of grief if you write down what you plan to say first. Not only does it give you a transcript, but it will make recording your audio much smoother.

There are times when you can't pre-transcribe - especially if you want to capture spur-of-the-moment interviews or reactions, but if you prescript everything else, your transcription crunch will probably be reduced.

The emergence of Web 2.0 has seen the emergence of dark gray text as a new standard in graphic design. I like it myself, but it's not with out controversy as can be seen in the classic blog article Has Your Designer Ever Heard of Contrast?

The contrast issue is simply just that you want to be ensure that the majority of your audience can distinguish text from background. And generally, the fuzzier your vision gets, the more important contrast becomes, so it's an accessibility issue (for low vision users, older viewers and migraine sufferers).

Contrast Analyzer

How do you determine if your contrast sufficient? My favorite tool has been the Juicy Studios Color Contrast analyzer.

You plug in hexadecimal values for a background color and foreground (text) color and it calculates a contrast differential. If the number is higher than 125, then you have sufficient contrast. They give you the formula (based on a W3C recommendation), so you can use it elsewhere.

Some examples.

• Black (#000000) on white = 255 (pass, but harsh)
• #333333 on white = 204 (pass)
• #666666 on white = 153 (pass)
• #828282 on white = 125 (pass, barely)
• #999999 on white = 102 (fail)

Why Gray Text Anyway?

One theory is that it's due to the rise of the LED backlit monitor. If you have one of these beauties, everything seems much brighter and the traditional black and white can be too much contrast.

The problem of gray text arises when a designer makes the contrast a little "too subtle". The color contrast analyzer is a good way to check yourself.

I've been finding that most color contrast issues can be fixed with very minor shifts...so just play around with the numbers until you find that subtle contrast that passes the test.

Superscripts/Subscripts as “Presentation”

Both HTML and XHTML include the SUP tag for superscripts and the SUB tag for subscripts. However, if you’ve been involved in the standards communities, you may be “warned” against using the SUP and SUB tags and told to use CSS instead.

"Now sup and sub are presentational tags and should be avoided because the presentation should be in the CSS." http://brunogirin.blogspot.com/2005_07_01_brunogirin_archive.html

"Since SUP is inherently presentational, it should not be relied upon to express a given meaning."
style-sheets.com

So why are SUP and SUB even listed within the XHTML standard if they are only presentational? My answer is that they are sometimes NOT presentational. That is, the position of the character is meant to convey additional information which would be lost otherwise. For many academic purposes, the use of CSS only could actually cause additional accessibility issues because a user could ignore your stylesheet.

Disabling Stylesheets

Paragraph D of Section 508 specifically states

“Documents shall be organized so they are readable without requiring an associated style sheet.”
http://www.section508.gov/index.cfm?FuseAction=Content&ID=12#Web

That means that if a user decides to disable your stylesheet (some low vision or color blind users do exactly this), then all CSS formatting information will be lost. If your user can parse your content without the superscript/subscript then all CSS is acceptable. An instance of this is trademark “TM” placement on a word. Your page is “prettier” if the “TM” sign is superscripted, but it’s not essential.

Superman^TM (superscript) = SupermanTM (no superscript)

If you use CSS positioning, but a user ignores your stylesheet, he or she will be able to parse the text in most cases. Although it would be even better to use the entity code &trade; (as in Superman™ = Superman™)

Academic Superscripts/Subscripts

In the academic world, superscripts and subscripts are usually there to indicate additional meaning, not just for the sake of typographical aesthetics. For example as style-sheets.com points outs, in math, 2 superscript 4 means 2 to the fourth power, but “2-4” is the number 24. Now if you use CSS positioning and your user ignores your stylesheet, they may not be able to understand the content.

2⁴ ≠ 24

 

Some users suggest options like “2^4” but that may not work in every case. For instance. in linguistics, g^w ≠ gw. The first letter with the superscript w means rounded g; the second is a true consonant cluster. Again if you use CSS, and the user ignores your stylesheet, the reader will lose the information. Even better, you can add aural styles to SUB and SUP tags if necessary for screen reader supper.

Entity Codes

You can avoid the SUP/SUB tag, in these cases but not with CSS. What you would do is find the entity code for superscript 4 (&#8308;) or superscript w (&#695;) and use them instead...and hope you’ve specified the right font for everyone. The lesson is - you didn’t replace SUP and SUB with CSS but with more meaningful content (i.e. entity codes). See links below for a list

• Math Super/Subscripts
• Phonetics (organized by letter)

By the way, entity codes may be the wave of the future, but have their own problems. Not all common fonts may support the special characters (while the SUP version will almost always work) and screen readers may not understand the entity code and may spell out “unknown”. At least with the SUP/SUB tag the chances are higher that the user will hear the content of the tag.

Conclusion

If your superscripts/subscripts are adding meaning and not just there to be “pretty”, consider using the SUB/SUP tags or the more modern entity code (assuming it exists for your character)...but the most dangerous path would be CSS only.