April 2012 Archives

Firefox ESR 10 - A Way to Slow Down Firefox Upgrades

| | Comments (0)

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.

MathML...On a Screen Reader

| | Comments (0)

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)

<math xmlns="http://www.w3.org/1998/Math/MathML"> <!-- xmlns link for IE 9 Support -->

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.

Distinguishing B(old) from STRONG Text with CSS

| | Comments (0)

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.