Recently in Accessibility Category

I love Firefox, but not necessarily the rapid upgrade cycle. The issue isn't so much the speed, but the fact that my plugins can't keep up, particularly my Firefox Accessibility plugins.

On the other hand, I don't want to miss security updates either. A solution I found was to install Firefox 10 ESR (for Extended Service Release). This will essentially freeze my system at Firefox 10, and the only upgrades I will be required to install will be the security upgrades - which are much less frequent.

The tradeoff is that I might miss some cool features in the newer Firefoxes, but I also know my plugins will keep working. I won't be able to stave off the upgrade messages forever though. When Firefox 17 comes out, the plan is that I will be asked to migrate to Firefox 17 ESR. Hopefully that won't come until some time after Memorial Day.

As part of the Penn State accessibility initiative, I've been working on how to accessify math/science courses along with others like World Campus and Dutton Institute.

Part of that has been figuring out how to post MathML on modern browsers, but the second part has been to determine if the output can be read on a screenreader. The answer is yes...on some browsers with the right plugins.

Screen Reader Results

I was able to get native MathML read aloud correctly on JAWS, but only on Internet Explorer with the MathPlayer plugin. For IE, you also need to ensure that the first line of the Math ML code links to the spec (see below)

Sadly JAWS and Firefox were not a good match and neither were Safari plus VoiceOver. The good news, many blind users do use the IE+JAWS combo, but many are moving to Mac. For these users, the alternative may still be an image plus apprpopriate ALT tag, particularly for multi-line equations.

So Close...Except for Browser Upgrades

The good news is that MathML is really becoming a viable option, but there are issues. One pointed out by my colleague Stevie Rocco is that many systems like ANGEL support only Firefox 3 and it's not until version 4 that improved MathML support is available. Similarly, not everyone may be upgraded to Safari 5.1 or Internet Explorer 9.

But I do expect that within 6-12 months, that could change, and MathML could mature into a key technology with relatively few quirks, like CSS and Unicode.

Although not a major accessibility blocker, many standards experts recommend replacing B tags with STRONG tags (and I with EM). If you are dealing with legacy documents, this can be trick because B tagged text and STRONG text actually look identical in WYSIWYG mode (and neither are read differently from normally formatted text on most screenreaders).

There are two solutions to deal with this. One can automatically replace the B tag with the STRONG tag in the HTML code. However, because the text looks the same, I find it's easy to overlook this step. So to spot offending tags, there's a CSS trick you can use.

If your goal is to eliminate all B tags, you can modify your CSS so that anything in the B tag shows up as a garish color (say red). See CSS example below:

b {color: red; font-weight:bold}

Once implemented, the Bold text will be magically transformed into a freaky color making the offending tag easy to spot in WYSIWYG mode. So long as the STRONG tag is just strong {font-weight:bold}, the visual outcome will be different.

Philosophical Note

A question that has vexed many a strandardista mind is why the B and I tags are still in every major (X)HTML spec despite the long-standing campaign against them. The one spec that eliminated them officially was XHTML 2.0, and that seems to have been superseded by HTML 5 (which still keeps B/I although only as a last resort).

I think the answer is that bold-face/italic formatting are inherently presentational. That is, when a content author clicks the B/I button they are not necessarily thinking - "I am emphasizing that strongly", but rather "I need to distinguish the text for some reason."

Sometimes it's emphasis, but sometimes it's for other reasons. I often bold face some non-English text, just to help Western eyes. In other words, bold face/italics along with color/text-size/font-face are accessibility accommodations for the sighted.

The fact that screenreaders skip over boldface and italics by default tells me that this is not information that someone listening to the text can really use. Natural speech does include intonation variations for emphasis, but writing those down in most written text can be very odd and very annoying (based on some novels I have read).

As far as I can tell, I know of only of only one argument for STRONG/EM with empirical consequences and that is translation into non-Western text where visual indicators of emphasis are something other than bold/italics. However, I am not anticipating that most Penn State documents will be translated in the near future.

While there are plenty of CSS workarounds for deploying format changes including re-styling headings, re-styling TH and CAPTION tags, contextual styling of menu links and even using obscure semantic tags like CITE, ADDRESS, ...there are times you want to adjust the visual formatting of a piece of isolated text unrelated to emphasis, I just cannot bring myself to write code like <span class="bold"> when the B tag is so much more succinct.

I just found a great resource on accessifying technical (STEM) diagrams, from WGBH NCAM, but there's one diagram they did not cover - the NCAA Basketball Bracket diagram.

Obviously, any kind of ALT diagram will be very very long and really, really complicated, so following a general tip from NCAM, I am not going to attempt it. Instead, I am going to discuss a text based alternative that might help more than just the visually impaired.

The bracket in its traditional form looks like spider web branching from the center, but really the important information you probably need is:

• Rounds and teams in that round
• Winners and losers
• Time, location of rounds (TV channels would be nice also)

Believe it or not, most of this can be accomplished by a series of lists/tables with headings. If you have dynamic pages, you can even tweak the presentation of the lists, but for this example I'll do the East Bracket plus first round.

I'll add that this is not the only possible solution. I'll also add that you are free to add color/size changes/bold via CSS, but you need to ensure that all information (e.g. the winner) is presented in text and not just via CSS formatting!

First Round

Second Round East Bracket (Main Tournament)

Key: [W] = Winner

Played in Pittsburgh (A)

• [W] Syracuse (1), vs.
  UNC-Asheville (16)
• [W] Kansas State (8), vs.
  Southern Mississippi (9)

Albuquerque

• [W] Vanderbilt (5), vs.
  Harvard (12)
• [W] Wisconsin (4), vs.
  Montana (9)

Nashville

• Cincinnati (6), vs.
  Texas (11), March 16 at 12:15
• Florida State (3), vs.
  St. Bonaventure (14), March 15 at 2:45

Pittsburgh (B)

• [W] Gonzanga (7), vs.
  West Virginia (10)
• [W] Ohio State (2), vs.
  Loyola (MD) (15)

Third Round (Boston)

• Syracuse (1) vs. Kansas State (8), March 17 at 12:15
• Vanderbilt (5) vs. Wisconsin (4), March 17 at 6:10
• Winner of Cincinnati/Texas vs. Winner of Florida State/St. Bonaventure,Time TBA
• Gonzonaga (7) vs. Ohio State (2), March 17 at 2:45

Sweet 16 (Boston)

• Winner of Syracuse/Kansas State vs. Winner of Vanderbilt/Wisconsin
• TBA (see Nashville schedule for teams) vs. Gonzonga/Ohio State

Elite Eight (Boston) - Determines East Bracket winner

• TBA (see above for teams)

Final Four (New Orleans)

• Midwest vs. East
• South vs. West

If you're being asked to accessify a Website, Firefox plugins can be some very handy tools to have, and I have recently discovered three new ones which extend my functionality in addition to the classic Accessibility Evaluation Toolbar .

All of these toolbars are designed primarily for spot checks on a single page. However, if your site is templated (even Dreamweaver templated) you can catch a lot of template errors doing a one-page check up. You can also quickly check objects which normally cause the biggest headaches - images ALT tags, ill-structured tables and improperly labelled form fields. Modern tools are also letting detect ARIA page structures (or the lack of them).

WAVE Toolbar

If you like the WAVE report (and I do), you may also want the WAVE Toolbar. This toolbar lets you do a WAVE scan on your current Web page, even pages which require a login. I've always liked the WAVE report because it captures a lot of data for multiple tests, and quickly lets you know where your problems are on the page.

Juicy Studios Toolbar

The studio that gave us the Colour Contrast Ratio Analyser also provides a Juicy Studio Accessibility Toolbar which includes (yes) a color contrast tool. which reports on every text/background combination on your page (a plus for more colorful home pages). They also provide a nice table analyzer tool which shows if a table has the SUMMARY and the TH attributes and checks for SCOPE.

Jim Thatcher Favelets

This Favelets set is from accessibility guru Jim Thatcher. They run similar tests as the other tools, but results are in pop-up windows which are a little more screen-reader friendly. It also includes a very nice ARIA tool (as does Juicy Studio). It also checks for the presence of a SKIP Link.

Penn State is implementing a centralized scanning service, but I like having these tools in addition to those...just in case.

You may have heard several accessibility experts say that implementing accessibility can improve your rankings in Google, but the article SEO and Accessibility Overlap documents the different WCAG 2.0 requirements that also makes your site more Google friendly.

The reason for all this overlap? As author Liam McGee comments:

Google[bot] is blind. Googlebot doesn't use a mouse. Googlebot sometimes has trouble with javascript. Like a blind person using screenreader software, Googlebot relies on structural cues in the content - denoting headings, paragraphs, lists and more - to make more sense of the page.

It just goes to show that you never know WHO could be visiting your Web site.

Within a PDF or even stylized text on a Web page, an important accessibility question is whether a piece of verbage is really text or is an image of text. For accessibility, this is important for determining whether you need to worry about the ALT tag or not.

A simple text for differentiating text versus image is to move your cursor to the text (mouse or arrow keys), then selecting it (mouse or SHIFT+arrow keys). If you are able to select/highlight each character one by one, then it is text.

However, if your cursor highlights the entire text piece all at once, then you probably have an image. For a PDF based on a scanned document, that means you won't be able to select ANY text on a page, which can be inconvenient for both sighted and unsighted users.

WCAG 2.0 Note

One item from the WCAG 2.0 accessibility guidelines is that if you have a choice between using stylized text or an image, choose text. Not only does it make accessification for screen readers, but it reduces file size and makes the page more accessible for low vision users.

WCAG Guideline 1.4.5 - If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text except for the following

You may have heard recommendations that a site in Dreamweaver is 1) more prone to being inaccessible and 2) difficulty to accessify. There are some nice accessibility benefits to using a CMS like Plone, Drupal or Movable Type. BUT if you are tied to a Dreamweaver-based environment DON'T PANIC.

Under the right conditions, a Dreamweaver site can be made to be 100% accessible...because at the end of the day its the code being created, not the tool that really counts.

Accessibility Advantages of a CMS

With a good CMS, you can get two huge advantages.

1. The templates out of the box often generate accessible code. For instance an accessible CMS includes an accessible search box and properly tags site navigation with appropriate list/header tags and often uses CSS to boot. That is a lot less work for a Web developer.
2. A good CMS also include a good WYSIWYG editor that supports accessibility in content from people who do NOT know HTML. It should be easy to insert sub headers, lists and ALT tags on images. A killer CMS will even give you good tables. That means accessibility can be accomplished without looking under the hood - yeah!

So...Why Dreamweaver?

With all the advantages listed above - why would anyone remain in Dreamweaver. One answer is the ability to customize code and CSS. A CMS can be customized, but a user has to investigate the CSS closely. Dremweaver is essentially a blank canvas.

If your scenario is one experienced Web person maintaining a relatively small set of pages, Dreamweaver can work.

The other advantage is the accessibility tools. To this day, I have not seen a better tool for generating accessible tables and forms quickly and cleanly. Dreamweaver also does a good job at CSS maintenance and other important tasks.

I'm on a lot of CMS platforms, and as crazy as it sounds to some, I use Dreamweaver to edit more complex content portions than cut and paste. Sure, I could use Notepad, but I've killed a lot of data tables that way. Dreamweaver has nice dual views that help keep track of WYSIWYG and code.

Static Site Tricks

if you are a Webmaster ready to migrate to a CMS (yet), you can manage to get some accessibility implemented with a few of these tricks.

1. Remember Global Search & Replace - Dreamweaver will let you replace one snippet of code with a more accessible one on multiple pages in one shot.
2. Consider Server Side Includes (SSI) - You can get some of the benefits of a CMS by using server side includes to insert template headers, footers and so forth on multiple pages.
3. Master your CSS - Dreamweaver will readily allow you to use CSS, but you have to follow through with it. CSS mastery is equally important if you want to tweak a CMS theme. Whenever possible, replace an inline formatting command with a link to a style sheet and you will go a long way towards a cleaner and more accessible site.
4. Use the Dreamweaver accessibility tools they gave you - Include an ALT tag when you insert an image, a caption and headers when inserting tables and all those IDs and LABELs if you are designing a form. It will never get any easier than at that time.

Why I Keep Advocating Dreamweaver

Far from being an accessibility barrier, Dreamweaver has the potential to be a powerful tool for a lot of Web developers semi-familiar with HTML but not quite comfortable with Notepad or BBEdit.

In fact, Dreamweaver is the platform of choice for the Lynda.com seminar on accessibility as well as is a platform for a WebAIM accessibility plugin. I'm glad I'm not totally alone on this one.