101 Browser-generated quotes

No one is advocating browsers automatically inserting quotation marks. No browser does this anymore.

Firefox and Opera insert quotes automatically. Otherwise, this article would be rather pointless, no?

posted at 01:47 am on October 18, 2006 by Jim O'Donnell

102 Browser-generated quotes

Browsers include thd quotation marks using CSS generated content in their default user-agent stylesheet. They do this because of the recommendations of the standard body for HTML 4.01 from 1999. CSS2 has provided this mechanism that makes the HTML 4.01 standard unnecessary. Their support for CSS generated content makes this simple to override. IE’s lack of support for CSS generated content makes it impossible for author’s to override. I think most web desigenrs know how to handle CSS generated content.

I read the thrust of this article about how to deal with IE’s lack of support for CSS generated content, especially in the context of the ‘q’ element where it’s necessary for authro’s looking to separate semantics from style. The article’s solution is not as elegant as Ian Oxley’s comment-based solution from comment #56.

posted at 05:15 am on October 18, 2006 by Rob Burns

103 JAWS,, Accessibility and CSS

Looking over the results for JAWS posted hrere its strikking that it doesn’t support aural or even speech CSS.
http://www.dotjay.co.uk/tests/screen-readers/abbreviations/

It is sad. Why would anyone pay $1,200 for this software (especially for web content) when there are free alternatives that work correctly. I would imagin anyone with a disability using JAWS is either faking or it’s part of some larger care-taker abuse and the authorities should probably be called to investigate.

posted at 10:58 am on October 18, 2006 by Rob Burns

104 But not surprising...

Our beloved IE doesn’t support the Speech module. To my knowledge, Opera is the only browser to have a degree of support. And I think I’m right in saying that Fire Vox gets it’s support for the Speech module directly from the CSS rather than from Firefox’s DOM, which it uses for pretty much everything else. This is because Firefox currently doesn’t support the Speech module in its DOM.

If the majority of browsers don’t support the Speech module, I think it’s hardly surprising that the likes of JAWS, which relies on browsers for such information, do not support these CSS features either. I’m not sure what JAWS does with browsers that do support the Speech module, because JAWS only works reliably with IE and Firefox.

As for using CSS pseudo-elements in user-agent styles, I think the point is that browsers shouldn’t even be doing that for us. The fact that it can be overridden using CSS is neither here nor there. Turn CSS off, the browser’s default styles are still there.

The fact is that the punctuation is still being controlled by the browser. Why? There is no question element for marking up questions so that browsers can put the appropriate punctuation on those – why do it for inline quotes? Besides anything else, it leaves too much room for browser error, when a human is perfectly capable of typing the required punctuation.

posted at 02:16 pm on October 18, 2006 by Jon Gibbins

105 The semantics of quoted text

By the way, if anyone wants a good resource on marking up the semantics of quotations in electronic texts, I can recommend quotations from Elements available in all TEI documents

posted at 05:55 pm on October 18, 2006 by Jim O'Donnell

106 Visual brwosers not using the speech media CSS

Jon Gibbins writes: “If the majority of browsers don’t support the Speech module, I think it’s hardly surprising that the likes of JAWS, which relies on browsers for such information, do not support these CSS features either.�

This is a bit like expecting visual browsers to use the a speech stylesheet when printing. It’s not going to happen. These browsers expose the DOM, including the stylehseets, to other applications, and htat’s the only support necessary for proper speech/aural CSS support. There are several solutions that use speech CSS and the list keeps growing as we discuss this: Fire Vox, EMacSpeak, Safari (with VoiceOver), Opera. We only needs one solution, but there are several. So regardless of JAWS limitations (and these are limitations that the excuse of it onlly being a screen reader doesn’t justify), there’s no reason to treat JAWS as the benchmark for accessibility. Obviously the benchmark has been set much higher. It is a grotesque disservice to the disabled communnity to encourage web authors to avoid semantic markup to cater to this lackluster solution.

When you keep saying JAWS is a screen reader, you make it sound like it’s some guy that sits next to you and reads your screen. It’s running on the computer, it has access to the DOM, it has access to the files. It can figure out what CSS is there and do the right thing. Obviously that’s what all of these free solutions do. And these CSS properties are also from 1999, so it’s not like it took JAWS by surprise.

posted at 12:23 am on October 19, 2006 by Rob Burns

107 Not some guy that sits next to you and reads your

There are several solutions that use speech CSS and the list keeps growing as we discuss this: Fire Vox, EMacSpeak, Safari (with VoiceOver), Opera. We only needs one solution, but there are several.

Rob, the solutions you have mentioned have something in common – they are all solutions for the Web. With the exception of Voice Over, the solutions are speech browsers, not screen readers. People use screen readers to make their computers accessible, not the Web. As far as aural CSS goes, we don’t have a solution.

It is a grotesque disservice to the disabled communnity to encourage web authors to avoid semantic markup to cater to this lackluster solution.

It’s a disservice to disabled people to not be practical about what we do. It’s frustrating that there aren’t effective solutions in place, whether it be because of limited support or a swiss-cheesed basis. Using inline speech marks doesn’t remove meaning – the text is quoted, it’s a quotation. Adding markup is useful – I don’t dispute that – but when markup does more harm than good, is it not a disservice to continue to use that markup? Just look at the accesskey attribute. It’s a great idea in theory, but problematical in practise.

It’s running on the computer, it has access to the DOM, it has access to the files.

I don’t know enough detail about how screen readers obtain information to comment adequately on this, but I do know that Firefox doesn’t expose aural CSS through its DOM – the sole reason that Fire Vox has to circumvent the DOM in order to support the CSS3 Speech module. I suspect it’s the same situation with other browsers.

Remembering that a screen reader is not just for the Web, ask yourself this question: does JAWS have a dedicated CSS engine? I don’t know the answer, but it doesn’t need an engine for presentational CSS – the browser handles CSS. So it follows that screen reader vendors would have to build any kind of support for aural CSS from scratch.

For the likes of Freedom Scientific to implement aural CSS support in JAWS, there needs to be an advantage to them for doing so – they’re a company at the end of the day. In all likelihood, both browser and screen reader vendors will probably have to make changes to get it to work. Until there is better support for aural CSS, few sites will use it. Until more sites use aural CSS, screen readers are unlikely to support it. Which came first… chicken or egg?

Perhaps one day aural CSS will work, but right now it doesn’t, so let’s be practical.

posted at 07:54 pm on October 19, 2006 by Jon Gibbins

108 effective solutions

Jim Gibbins writes: “It’s a disservice to disabled people to not be practical about what we do. It’s frustrating that there aren’t effective solutions in place, whether it be because of limited support or a swiss-cheesed basis. �

But you keep saying that and it’s clearly not true. Why is that? I listed several solutions that I’m aware of and whether they are just aural browsers or screen readrs doesn’t matter. The point is the work correctly. Incidentally, you’re wrong about the screen reader issue too. VoiceOver aand EmacSpeark are also screen readers and they handle CSS aural / speech properties correctly.

There are so many falsehoods in whay you’re saying I don’t know where to begin. Here’s a list of corrections.

There are many effective alternative to JAWS than handle CSS and semantic markup correctly.
Using W3C recommendatikons for semantic markup and aural / speech presentation are effective ways of raching the visually impaired.
Firefox does expose aural properties in its’s DOM.

You keep saying the opposite of all of this is completely false. And all of your advocacy agasint the visually impaired seems to be only due to a misguided attempt to justify Internet Explorer‘s lack of standards support.

What do you do in you’re spare time, steal Christmas?

posted at 12:48 am on October 20, 2006 by Rob Burns

109 Avoiding semantic markup

Thanks Rob – another insightful and cogent post.

I just wanted to point out – noone’s encouraging web authors to use unsemantic markup. Far from it. It’s just the semantic description of a quote may include the surrounding quotation marks. Equally, it may not – this depends on context and the quote in question.

Some semantic markup languages (TEI-Lite, XHTML 2) give authors the flexibility to markup quotes in either fashion. HTML 4, unfortunately, does not and so workarounds are needed if the quote, semantically, includes quote marks and is enclosed by <q> tags.

Hope that clears up that bit of confusion.

posted at 02:04 pm on October 20, 2006 by Jim O'Donnell

110 Avoiding semantic markiup

No, it doesn’t clear up the confusion. It adds to the confusion in the same way you’ve been doing all along. In all practical terms, HTML 4 (1999) along with CSS 2 (from 1998) does allow flexibility with semantic markiup (just like the proposed XHTML 2 draft). IE does not provide this flexibility.

posted at 07:06 pm on October 20, 2006 by Rob Burns