Long Live the Q Tag

by Stacey Cordoni

107 Reader Comments

Back to the Article
  1. Oops, I meant the DFN tag there.

    Copy & paste the code below to embed this comment.
  2. Firefox sometimes miscalculates the width needed for a <q>quoted text</q> when you use

    q:before, q:after {
      content: “”;
    }

    So I have seen italic quoted text with a length of two lines or longer to overflow its container. The fix is:

    /* fallback for Safari 2.0 */
    q:before, q:after {
      content: “”;
    }

    /* for browsers with better CSS 2 support */
    q:before {
    content: no-open-quote;
    }
    q:after {
    content: no-close-quote;
    }

    Copy & paste the code below to embed this comment.
  3. Oops, Textile ate my CSS comments…

    // fallback for Safari 2.0

    q:before, q:after { content: “?”?; }

    // for browsers with better CSS 2 support

    q:before { content: no-open-quote; }

    q:after { content: no-close-quote; }

    Copy & paste the code below to embed this comment.
  4. What is the advantage of this solution compared to placing conditional comments around the q element? If you use the following code, all problems are solved without css and polluting markup, right?

    <q><!—[if lte IE 6]>“<![endif]—>Yeah!<!—[if lte IE 6]>“<![endif]—></q>

    If future IE versions still don’t support the q element you will have to ajust all conditional comments, but that is the only disadvantage I can think of.

    Copy & paste the code below to embed this comment.
  5. I’m very uneasy about using generated content to add punctuation to a document. Punctuation is part of the text, giving it structure and meaning. So I don’t like the idea of adding it via CSS, which is meant for decoration and styling. Imagine, for example, if you removed all of the capital letters and full stops from this article, then added them via CSS. You would have removed a large part of the meaning from the text.

    If you leave the quotation in your document, and use typographically correct punctuation, is there any need to use <q>? Surely, as others have pointed out, the semantic structure of the text is conveyed by the punctuation on its own. Punctuation is semantic markup!

    There was a discussion of this recently on “Accessify forum”:http://www.accessifyforum.com/viewtopic.php?t=5823 which might be useful.

    Joe Clark’s book has a useful “section on quotations”:http://joeclark.org/book/sashay/serialization/Chapter07.html#h2-2255 too.

    Copy & paste the code below to embed this comment.
  6. If people serve XHTML 1.x, they should use application/xhtml+xml (see Ian Hickson’s arguments and W3C’s note ); if people use XHTML 2.0, they (probably) will be required to use application/xhtml+xml. Most browsers that can render application/xhtml+xml, and all browsers that make that support explicit in their default Accept header, have a partial implementation of Q that will serve as a usable fallback.

    For the record, it was my understanding that Safari does support application/xhtml+xml, but from my testing I have not seen it sent with the Accept header. Regardless, can someone please give their experience working with the q element in Safari?

    When JAWS uses IE as its rendering engine shouldn’t it inherit IE’s conditional comments? If so, shouldn’t a behaviour to add quotes around a q element still be applied? I’ve read the comments here and understand that screen readers react different when the q element is there, but I am still confused as to what exactly that distinction is and how that is not a suitable replacement (beyond the requirement of JavaScript being enabled and semantic arguments about the placement of quotes in relation to the q element aside). Does this result in double quotes?

    Copy & paste the code below to embed this comment.
  7. Readers may also be interested in reading Gez Lemon’s solution:
    “Fixing Quotes in Internet Explorer”:http://juicystudio.com/article/fixing-ie-quotes.php

    Hopefully this will at least get quotes marked up in a useful way for the more recent browser/screen reader combinations. Of course, the downside is that it requires JavaScript.

    Copy & paste the code below to embed this comment.
  8. We decided to leave it “q tag”? because we usually go for conversational style unless it causes confusion. I tend to think that anyone passionate about the q element isn’t likely to be confused about it.

    Yeah. As you will enjoy it when your car mechanic calls tyres “the things at the bottom of the car”, right? “Q tag” (above all, in the headline, @John) is just false, and neither “conversation style” nor “anyone passionate” will change that. Sorry. (No, I’m not, but it sounds polite.)

    Copy & paste the code below to embed this comment.
  9. For me, this was a truly unproductive article. This hardly constitutes “best practices.”  I’d go as far as to say that this article should be removed from ALA for its suggestions and its inconsistencies.  Not only does the article encourage someone to make their markup inaccessible, it completely bungles the idea of creating Standards Compliant markup.

    http://www.w3.org/TR/html4/struct/text.html#h-9.2.2

    Imagine if thousands of web developers actually took the recommendations in this article and created millions of web pages that completely disregard the W3C standard.  We’d have billions of embedded quote characters in our markup that shouldn’t be there.  Now try browsing these articles from a mobile phone or a screen reader. 

    I honestly can’t think of a bigger disservice for the web from the ALA than the recommendations in this article.

    Copy & paste the code below to embed this comment.
  10. The <cite> element, which “Contains a citation or a reference to other sources,” is better for titles of books than the <q> element. Book titles in English are usually in italics, not quotation marks. Of course, you’d need to make <cite>s italic in your style sheet, but they’re more accurate than <q>s.

    http://www.w3.org/TR/html4/struct/text.html#h-9.2.1

    Discussion here:
    http://www.simplebits.com/notebook/2003/09/23/simplequiz_part_viii_titles.html

    Copy & paste the code below to embed this comment.
  11. Once the page is processed and the Q tags are replaced with quotation marks, JAWS will no longer recognize that as a quote.

    Sorry, this seems to be incorrect – JAWS 7.10 will announce speech marks embedded in the text, but ignores speech marks generated by the <q> tag. There’s some discussion here, including a test with JAWS in Firefox and IE:
    http://accessifyforum.com/viewtopic.php?t=6256

    Copy & paste the code below to embed this comment.
  12. From what I’ve seen, the best solution is from “as days pass by”:http://www.kryogenix.org/days/2003/04/03/javascriptThe as it will determine if the browser supports the style.

    There is, of course, one major downside to the solution: it uses Javascript. If a user turns off Javascript, then this solution falls flat on its face.

    Other than that, it is feasible to modify the code so it checks for nested quotes, and the markup is still semantically correct.  This also works in Lynx, and while I haven’t tested it, I suspect it would play nicely with screen readers as well.

    I’m not sure that I agree with the idea of punishing those browsers that are closer to standards; forcing compliant browsers to remove the quotes as we add them in by hand seems like an accident waiting to happen.  As many have mentioned already, the end result is semantically incorrect, and you’re doing a disservice to the developer to require them to add both quotes and the <q></q> tags.

    Much of what is preached in this publication is about the separation of structure from style and presentation, and the solution proposed by Ms. Cordoni goes against this ideal.

    To be fair, when designing a site, you must take your audience into consideration, and as a vast majority of Internet users browse with Internet Explorer, the quirks of that browser must always be taken into account.  I would caution developers to carefully weigh the benefits of a solution like that proposed in the article against the costs associated with alienating or depriving service from those with disabilities (especially in light of “recent legal actions”:http://arstechnica.com/news.ars/post/20060910-7705.html targeting Target).

    Copy & paste the code below to embed this comment.
  13. Would it be simpler to just add quotes within conditional comments for IE/Win

    e.g. Did you know <!—[if IE]>“<![endif]—><q>The quick brown fox jumps over the lazy dog</q><!—[if IE]>”<![endif]—> contains every letter of the alphabet?

    Copy & paste the code below to embed this comment.
  14. Adam Wilson – I would caution developers to carefully weigh the benefits of a solution like that proposed in the article against the costs associated with alienating or depriving service from those with disabilities (especially in light of recent legal actions targeting Target).

    I’d say the Target lawsuit is, frankly, irrelevant scaremongering here. The technique in this article is fully accessible to screenreaders.

    Omitting the quote marks, as per the HTML spec, would make the quoted text inaccessible in JAWS, at least.

    This is a case where the HTML 4 spec gets it wrong. The fix is to remove the UA-generated quotes, via CSS, as suggested in this article.

    JAWS test cases”:http://www.dotjay.co.uk/tests/screen-readers/q-element/
    (thanks to Jon Gibbins for those.)

    Copy & paste the code below to embed this comment.
  15. Jim,

    If JAWS and other screenreaders don’t use the <q> tag, then why should anyone use it in their markup?  It’s a shame that the HTML spec is so far off base.

    Does anyone know of any browser, application or utility that actually makes use of the <q> markup?

    It seems to me that if the XHTML2 spec requires that UAs not add quotes to <q> tagged content, and screenreaders ignore the tag, then the tag serves no purpose and we should be using quotes in our source code exclusively.

    Copy & paste the code below to embed this comment.
  16. If JAWS and other screenreaders don’t use the <q> tag, then why should anyone use it in their markup? It’s a shame that the HTML spec is so far off base.

    I guess it’s no less useful than <dfn>, <kbd>, <cite>, <code> and all those other wierd little inline phrase elements. You might want to style inline quotes with CSS, for example. <q> would give you a markup hook to use for that.

    Copy & paste the code below to embed this comment.
  17. PS Can someone change this line in the original article

    The Q tag is neccessary for semantic markup and for screen readers.

    as it’s just plain wrong. The <q> tag is not necessary for screenreaders.

    Copy & paste the code below to embed this comment.
  18. Does anyone know of any browser, application or utility that actually makes use of the <q> markup?

    My tests that Jim linked to are very simple. I haven’t yet had time to investigate further. However, it seems that the <q> element may be available to assistive software (suggested by the occasional pause in reading), but JAWS 7.10 doesn’t make use of the element. If that’s the case, then other screen readers may have better implementations – I may get time to test this later. However, if the browser doesn’t make <q> elements available to assistive software (in the same way that IE doesn’t support <abbr>) I don’t hold much hope for other screen readers.

    It seems to me that if the XHTML2 spec requires that UAs not add quotes to <q> tagged content, and screenreaders ignore the tag, then the tag serves no purpose and we should be using quotes in our source code exclusively.

    The idea behind <q> is to add meaning and a neutral one that can be interpreted correctly by the user agent depending on context. For example, different glyphs are used in different languages for delimiting quotations.

    We’re talking about punctuation though. Typographically speaking, I just cannot understand the decision to allow user agents control over the punctuation. We don’t do that for full stops at the end of paragraphs, do we?

    In his book, Joe Clark gives an “example where there’s a French quote in the middle of an English sentence”:http://joeclark.org/book/sashay/serialization/Chapter07.html#p-2410 (although I’m not sure I’d even use <q> there). The fact is that the sentence is English, so you would hope for English glyphs, not French ones.

    My current approach is to just use quote characters in favour of the <q> element. At least until I’m satisfied with an approach which stops user agents doubling up the quotation marks I use.

    Copy & paste the code below to embed this comment.
  19. Jim Dalton said:

    Chris Botman points out the XHTML2 specs for the <q> element. These specs are obviously not set in stone, but shouldn’t we keep an eye toward them for forward compatibility?

    XHTML 1.x is not forward-compatible with XHTML 2. This is by design of the W3C working group that is creating XHTML 2.

    If the W3C were to announce a more compatible “next step” markup language, it would not be called XHTML 2 and would have little to do with that spec.

    Copy & paste the code below to embed this comment.
  20. As a follow up to my own comment (#31) I feel I should remark on what I am doing currently. My current style sheet lets most browsers do their thing, since Firefox/Opera/etc. seem to be doing a decent job in my opinion. I then have a conditional comment that applies an IE only style sheet that italicies the text, shrinks the font to 90% of whatever it currently is (hence to differentiate between quotes in already italicized elements), and I apply a behaviour (which will of course only run if JavaScript is enabled). The behavior I am using is a modified version of Simon Willson’s method of fixing quotes, but in doing so I have it also apply some styling that undoes the italicizing and brings the font size back to 100%. I’m currently thinking about removing either the rule that sets the italics, or removign the rule that removes the italics if JavaScript is enabled, but I have not yet come to a conclusion.

    Copy & paste the code below to embed this comment.
  21. IE6 and 7 do support the Q tag. They do not add quotation marks to it, but they do recognise it as markup. So you can still style quotes in a different colour. It’s just that the level of support differs from other browsers. Perhaps we need to be clear about this, as readers might think IE doesn’t support the tag at all from what is written here.

    Copy & paste the code below to embed this comment.
  22. The more, the merrier!

    Copy & paste the code below to embed this comment.
  23. but this degree of hostility’s a bit uncalled for.

    It wasn’t meant to be hostile, just precise. No offense.

    Copy & paste the code below to embed this comment.
  24. I’d just like to comment that I think that using Javascript is much better than turning off the default styling of quotes and adding the entities manually. A couple of posters have suggested a three-pronged attack:

    1. rely on the default rendering of quotes in standards-compliant browsers;
    2. include a stylesheet which targets IE 7 and below, using conditional comments, to make quotes more obvious (eg. italics, a stylised quotation mark graphic at the beginning, different colour; there are plenty of possibilities)
    3. finally, include a script which will only run in IE 7 et al. which adds smart quotes and removes the special styling by adding a class defined in the aforementioned stylesheet.

    This strategy should fix the problem beautifully for most configurations, except when an IE user turns off Javascript, in which case quotes are at least visible and distinguishable. In fact, this is precisely the solution I have implemented for a recent website, and will continue to use in the future. The overwhelming majority of users (not to mention content authors) will benefit from what I consider to be the main boons of the <q> tag:

    • smart quotes and automatic quote nesting, removing the need to keep track of quotes mentally when writing;
    • different quotes and nesting rules for different languages;
    • clean, logical markup.

    Trying to do all of this manually is a pain; it’s much easier to define once what sort of rules to apply to quotes in given languages, and henceforth allow the browser to apply them. All the author of a document needs to deal with is tagging their quotes and optionally specifying a language. In my opinion, this is the embodiment of all that’s good about markup and generated content; actually putting the quotes in the markup makes about as much sense as putting a bullet at the beginning of an unordered list item, or numbering your ordered list items manually.

    And while I love so much of the stuff which XHTML 2 will bring in, I don’t think that the decision to make authors manually insert quote marks is a good one—especially since any future user agents which parse XHTML 2 are likely to have far more standards compliant than the current offerings.

    Finally, can I just congratulate Ian Oxley on an extremely inventive solution. For the reasons stated above, I wouldn’t use it (not to mention that it isn’t terribly attractive); however, it is the first pure, valid markup solution I have seen which will work perfectly in almost every user agent in current use—except for IE 4 and maybe Netscape browsers, but who uses those?—without relying on server-side scripting. Very original, I’m impressed!

    Copy & paste the code below to embed this comment.
  25. Can I just ask what the heck happened to the first few lines of my posting? Apparently Textile decided not to make it a paragraph!

    Would an editor mind fixing this for me? The preview script gave no indication of this.

    Copy & paste the code below to embed this comment.
  26. “I love single letter tags” wrote Dallas Ransom. The problem with such tags is obvious though: they don’t describe what they are. What does Q represent? A “queue”? A “quiz”? In retrospect, from the point of view of XHTML and XML, such tags as Q, B, U and I were shortsighted. They should have been the word in full, eg: QUOTE, BOLD, UNDERLINE and ITALIC. Yes, sure it’s easier to type a single letter, but only if everyone knows exactly what it means. With the full word, there is no ambiguity.

    What always irked me was that you had Q, but then BLOCKQUOTE! It would have been better to use a shorter word than BLOCKQUOTE. Or perhaps use a single QUOTE tag and allow an attribute to define if it were inline or not.

    As for the debate at hand here, it strikes me that any approach requiring something the user is likely to turn off is not ideal, but there are levels of conformance we can hope for. Eg:

    1. A solution that uses JavaScript. I say this is a BAD IDEA as some companies insist it is turned off. Users also may surf without it for safety reasons. (I know one who does.)

    2. A solution that uses CSS. This is better than above, but there is still the chance that CSS is turned off. The stylesheet may also fail to load.

    3. A solution that uses images. This may apply to people with slow connections who prefer to surf without images. Or again, the image may fail to load. I’m not sure which level of conformance is safer to allow for – people surfing with images off or CSS off.

    4. A solution that uses a plug-in, such as Flash. Again, I know someone who blocks Flash, preferring to surf faster without it, so we need to consider such users. They are likely to be in the minority, but who knows?

    5. Then there are combinations of the above. What if the user has turned everything except plain text off? Can they still see the quotes?

    My advice would be to follow Mark Pilgrim’s note at the end of his post The Q Tag…

    http://diveintomark.org/archives/2002/05/04/the_q_tag

    …also linked at the start of this article, where he has chosen a server-side solution to allow for IE. Or we can use IE conditional comments as suggested in at least two comments here.

    Be aware of a new bug in IE7 though! Comments can become elements! You can even style them! Unfortunately I can’t give a direct link as Textile is converting the dashes in the URL to deleted text! But a related article about this is here:

    :before and :after in IE7 and below:
    http://nanobox.chipx86.com/blog/2006/07/before-and-after-in-ie7-and-below.php

    This may also be useful in tricking IE6 or 7 to use :before and :after to add quotation marks! Though I’m not sure it’s possible.

    Copy & paste the code below to embed this comment.
  27. Jeffrey Zeldman said:

    XHTML 1.x is not forward-compatible with XHTML 2. This is by design of the W3C working group that is creating XHTML 2.

    Fair enough. I’ll take your point one step further and note that the XHTML2 spec explicitly requests that the document not be normatively referenced, which in a sense renders any talk of XHTML2 here moot.

    I guess, however, that I took this whole article and the ensuing conversation to be an “open” discussion on the subject of the <q> element. As someone else pointed out, the article unequivocally contradicts the existing XHTML1/HTML4 spec for <q>:

    Visual user agents must ensure that the content of the Q element is rendered with delimiting quotation marks. Authors should not put quotation marks at the beginning and end of the content of a Q element.

    I could be mistaken, but I read “must ensure” as a requirement that quotation marks be rendered by the browser, which negates the option of including them outside the q element as the author advocates.

    I guess what I mean to say is, if I’m responding to an article that advocates breaking the current rules, I’m at least going to advocate breaking the rules in such a way that (hopefully) means following the rules at some point in the not-so-distant future.

    To be honest though, after reviewing the discussion that’s ensued here, my conclusion is it’s not really worth using the Q element at all for now, at least not for me. I’ll wait for the day when XHTML2 or whatever else comes along defines it in such a way that we can all use it consistently without breaking any rules.

    Copy & paste the code below to embed this comment.
  28. Jim and Jon, many thanks for bringing this data to the discussion.

    Thanks. I’m dismayed, though, that people are continuing to post comments promoting inaccessible markup, in which the punctuation marks are removed from the text. I understand that they want to comply with the HTML 4 spec. I just don’t understand why we have to comply with the spec when it promotes the creation of inaccessible documents.

    From reading both the article and the comments, I get the impression that there’s a lack of understanding in the semantic design community of how screenreaders actually read HTML, and how blind people use web pages. Oh dear :(

    Copy & paste the code below to embed this comment.
  29. Absent actual test results provided by the author, I reject the claim that Q is somehow an accessibility benefit.

    In languages that use different opening and closing quotation marks, including variants of English other than British, the use of such quotation marks accurately demarcates a quotation. The British English case is ambiguous because apostrophe and single closing quotation mark are ambiguous (also in Unicode); the same will be true of even-numbered nested quotations (using “ ”˜Â ” ”˜ ‘ ”? ’ ”? notation). Another ambiguous example would be Swedish, where opening and closing quotation marks are commonly both “?. But there are many languages with unambiguous quotation marks. We’re supposed to use them for typographic correctness, and they work fine. Why do anything else?

    This is indeed a solution in search of a problem. We don’t have to use a semantic element if we know it doesn’t work (Cf. OBJECT). Hypothetical semantics that break browsers or that break in browsers or that cause more trouble than they avoid are no good to us at all.

    Copy & paste the code below to embed this comment.
  30. Erin: Thanks very much for fixing that and the superfluous repeated comment which I posted. :)

    Question: how good is screenreader support for aural stylesheets? I gather that they are being phased out because it is bad to none, which is a real shame; if they did, it would be easy enough to add some audio for cue-before and cue-after to quotes, and maybe some other styling, since I suspect that:

    John said [pause] quote Shall we go get some ice-cream? unquote

    …would be rather nicer to hear read aloud (and not to mention less ambiguous) than:

    John said quote Shall we go get some ice-cream? quote

    (Strong emphasis above is meant to indicate that other aural styling could be applied to distinguish quotes.)

    However, I confess that as Jim predicted, I didn’t know how screen readers read my quote tags until I reading this thread. At your implied suggestion I will download Jaws once I get some speakers/headphones. But since I’ll be moving back to campus tomorrow and probably won’t have time to get any in the next few days, I would appreciate it if anyone more knowledgeable would explain if what I’ve outlined is possible, and if it would even be preferrable.

    Personally, I think the Q element is very useful, especially since the choice of quotes basically comes down to locale (which Q provides) and “house style” (which can easily be defined in the stylesheet). I don’t deny that quote marks themselves are perfectly meaningful, as much so as the question mark; I simply prefer to exploit the flexibility and simplicity which Q would provide if it were implemented correctly. Since I have a script and procedure to guarantee at least some level of functionality across most browsers and configurations (screenreaders excepted from comment due to inexperience), I generally use them without reservation!

    Copy & paste the code below to embed this comment.
  31. if they did, it would be easy enough…

    That is,

    …if they did support aural stylesheets, it would be easy enough…

    Copy & paste the code below to embed this comment.
  32. I remember that back in the day my teacher, a short woman packed with a great heart for teaching, told us about the q tag… This was back in the day of N vs. IE… love the memories.

    Copy & paste the code below to embed this comment.
  33. Personally, I think the Q element is very useful, especially since the choice of quotes basically comes down to locale (which Q provides)

    I’m not sure about this. An article from ALA, say, is written in US English, so uses US punctuation and marks up quotes with English double quotes. Someone in France might download the article and read it in English, but the quotes would remain English double quotes.

    If the article were translated into French, then the quotes would change to French double caret marks, but this would be part of the translation process. The quotes would then remain French quotes even if the French article were read in the US by an English speaker.

    So the punctuation of quotes is set by the author’s choice of language, in which case why have the user-agent insert the quotes? They aren’t going to change from one reader to the next, they’re part of the text content and, ultimately, control over them lies with the author, not the user-agent.

    Copy & paste the code below to embed this comment.
  34. If CSS if off, this looks quite terrible.

    Copy & paste the code below to embed this comment.
  35. Isn’t it wrong to have the browser render what is essentially punctuation.  I’m all for the q tag to seperate it from normal text, but why have the browser render quotation marks?  why don’t we then have tags for <question>(?), <exclamation>(!), or just regular <sentences>(.)?

    IMO, the browser shouldn’t render punctuation… it should be the job of the writer to add the correct punctuation and the q tag should be used only to style that text accordingly.

    Copy & paste the code below to embed this comment.
  36. Accomodate a broken browser by breaking the ones that work? 
    No thanks.

    Copy & paste the code below to embed this comment.
  37. Accomodate a broken browser by breaking the ones that work? No thanks.

    But the browsers that don’t recognise <q> include JAWS and Home Page Reader so “Accomodate a broken browser” = “Accomodate users of screen readers.”

    I think I’m beginning to sound like a broken record.

    The technique described in the article works with screen readers. The <q> tag as described in the HTML 4 spec does not. Therefore, from an accessibility point of view, Firefox and Opera are broken.

    Copy & paste the code below to embed this comment.
  38. I noticed that the Snapshot to this article is a paragraph with the quotes around it. Shouldn’t this be a blockquote or use the q element? I found this to be fairly funny given the current article.

    Jim: It looks to me like Firefox/Opera are the ones that work correctly, and that it is JAWS and Home Page Reader that are broken. You claim that the article’s technique does works even in screen readers (good), but it is a hack many people here are upset about hearing as it’s not the way the spec was supposed to be implemented. Because IE is so prevelent, we do understand the need to get that to work, as we understand the need to get screen readers to work. Finding out that the popular screen readers are just as broken should come as no surprise to us, as JAWS and Home Page Reader rely on IE. Now, it’s my believe that condtional comments to add the quotes for IE and IE derivative browsers is the best method (with web browsers styling for non-JavaScript enabled). My personal preference is for Simon Willison’s solution. Now, of course this doesn’t fit the case where JavaScript is disabled in screenreaders, as (I assume) most developers here don’t really know enough aural CSS like they do screen. Can you offer some suggestions?

    Copy & paste the code below to embed this comment.
  39. Hi Brian, “Jon Gibbins tests”:http://www.dotjay.co.uk/tests/screen-readers/q-element/ (discussed in an earlier comment) showed that JAWS running on Firefox ignores quote marks generated by the <q> tag too.

    As Joe Clark pointed out, you don’t have to follow the HTML spec when the spec is clearly broken. I’d advise ignoring <q> and using proper punctuation to mark up quotes, or use the <q> tag and the technique in this article to remove generated quote marks in Firefox and Opera.

    Copy & paste the code below to embed this comment.
  40. Now, of course this doesn’t fit the case where JavaScript is disabled in screenreaders, as (I assume) most developers here don’t really know enough aural CSS like they do screen. Can you offer some suggestions?

    Another of my tests (currently JAWS-only) notes that aural CSS is next to useless, with only Opera being of any interest:
    “Abbreviations and Screen Reader Support for CSS2 Aural Style Sheets / CSS3 Speech Module”:http://www.dotjay.co.uk/tests/screen-readers/abbreviations/

    Unfortunately, the whole implementation of <q> is ruined by a badly considered recommendation, causing browser inconsistency and leaving assistive software unsure what the heck to do.

    Copy & paste the code below to embed this comment.
  41. In my opinion, the best way is to avoid Q tags altogether.

    I don’t want to trust anyone else—particularly not a computer program—to decide what’s the best way to punctuate my writing. So what if Norwegians have a different way of punctuating their quotations? If someone in Norway is reading my website, it’s still an English website, so I still want it punctuated in my (English) way. If someone wrote a Norwegian website, complete with Norwegian-style punctuation, I’m sure they’d be similarly annoyed if an English browser altered it.

    As for screen readers, they should be able to change their tone accordingly when they encounter a bit of text surrounded by quotation marks, just as they pause when they encounter a comma.

    I wouldn’t mind using the Q tag if it was harmless. But it’s not harmless—it adds content to my content (and in an unpredictable way, too). OK, I know the spec says that we should always use Q tags, but I don’t see why we can’t carefully disobey certain things in the spec.

    As far as I can tell, using quotation marks without Q tags causes no problem for anyone. Am I wrong on this?

    Who actually benefits from the use of the Q tag?

    Copy & paste the code below to embed this comment.
  42. I’m not sure if some of these remarks are meant to be facetious, but they need correcting just in case impressionable youth come away not getting the joke. The W3C recommendations concerning the “˜q’ element and the “˜before’ and “˜after’ pseudo selectors and the “˜content’ attribute are not the broken part. Every user-agent I’m familiar with supports those consistently except for IE. There’s all this talk of a technique like this being needed until IE 6 and IE 7 become obsolete, but they’re actually obsolete already and we still need to find a solution because they’re the most popular browsers despite their obsolescence.

    I would imagine that if JAWS really doesn’t support speech styling (and I find that dubious) that it will not last long in that market. Why would anyone who needs to use the web and has visual disabilities tolerate a user-agent that doesn’t support CSS. That largely defeats the purpose of accessible user-agents.

    Also there are several comments that lump quotation marks with other punctuation. However they are different which is shy the W3C recommendations treat them differently. Quotation marks are typically only one of two ways publishers display quotations. Often times quotations will be displayed as indented blocks of text when they exceed a certain number of words (e.g. 25 words). I’m not talking about a block quotation that contains paragraphs and the like but a straight text quotation that exceeds a certain number of words. This is clearly an issue of separating semantics from style. A quotation is the semantic. Whether that semantic is presented with quotations marks before and after it or whether it’s presented as an indented block is the style. Likewise in aural browsers, the quotation may be read by a different voice to indicate its a quotation. There are several semantic constructs that have perhaps less importance than a quotation that are also typically placed within quotation marks. By removing the semantic “˜q’ element and lumping that with all of the others we lose that semantic distinction.

    Finally, I am surprised at how much leeway the web community gives Microsoft who is solely responsible for all of the clamor, debate and in-fighitn among web designers as they try to find solutions to this dilemma created by Microsoft. How difficult would it be to fix the “q”? element (for those of you who don’t do application programming, I’ll give you a hint: not very difficult at all). They’re clearly jerking us all around and we end up fighting amongst ourselves.

    Copy & paste the code below to embed this comment.
  43. Rob, none of these comments are meant to be facetious – just practical and factual.

    IE is broken in terms of supporting the spec. I don’t think anyone has said otherwise. However, in my opinion, the spec should never have taken control of punctuation away from the writer.

    Aural CSS never took off and support is very limited in browsers. If you find that dubious, run some tests. Screen readers don’t support CSS, browsers do. Screen readers rely on browsers for information. And JAWS is a well-featured screen reader. Aural CSS support will have very little impact on its market life. Now if browsers offered better supported and the screen readers and browsers “talked” more, that’d be great!

    Incidentally, CSS2 Aural CSS is depracted in CSS3 in favour of the Speech Module, so I can’t see Aural CSS getting increased support.

    How are quotation marks different to other punctuation? I don’t understand. In English, there are different rules for how quotation marks are used, where they are positioned, etc. Usage of punctuation requires human control over that punctuation, just as accessibility testing requires a human to run manual checks. How can you support that software should be in control of any kind of punctuation?

    I’m not saying that the q element is worthless – it does add meaning to a document for software. But it is next to useless in practice at the moment. I hope this changes.

    Copy & paste the code below to embed this comment.
  44. (Sorry – something weird happened to me post…)

    Rob, none of these comments are meant to be facetious – just practical and factual.

    IE is broken in terms of supporting the spec. I don’t think anyone has said otherwise. However, in my opinion, the spec should never have taken control of punctuation away from the writer.

    Aural CSS never took off and support is very limited in browsers. If you find that dubious, run some tests. Screen readers don’t support CSS, browsers do. Screen readers rely on browsers for information. And JAWS is a well-featured screen reader. Aural CSS support will have very little impact on its market life. Now if browsers offered better supported and the screen readers and browsers “talked” more, that’d be great!

    Incidentally, CSS2 Aural CSS is depracted in CSS3 in favour of the Speech Module, so I can’t see Aural CSS getting increased support.

    How are quotation marks different to other punctuation? I don’t understand. In English, there are different rules for how quotation marks are used, where they are positioned, etc. Usage of punctuation requires human control over that punctuation, just as accessibility testing requires a human to run manual checks. How can you support that software should be in control of any kind of punctuation?

    I’m not saying that the q element is worthless – it does add meaning to a document for software. But it is next to useless in practice at the moment. I hope this changes.

    Copy & paste the code below to embed this comment.
  45. Rob has a point when he says quotations don’t need to have quotation marks around them. I can imagine designs where quotations are displayed in italic, for example.

    So there is a difference between meaning and layout, and I don’t see a reason why a browser should automatically add quotation marks. Quotations usually have quotation marks, but not automatically. By the way, does anybody know how quotations are handled in non-latin script languages like Japanese?

    If the browser wouldn’t add them automatically, you could decide if you add them either manually in the code or with CSS :before and :after. Thus we wouldn’t have to discuss which way is best to get rid of them. I assume that’s the reason why XHTML 2.0 has dropped automatic quotation marks.

    Copy & paste the code below to embed this comment.
  46. Martin, I agree with you, but I’m a bit lost now. If Rob’s point was that quotations don’t need to have quotation marks around them (e.g. in different languages), it negates his point that IE is broken and the W3C Recommendations are correct.

    (Also, would an editor be kind enough to delete my previous duplicate post? I have no idea what happened, but my comment didn’t appear the first time I submitted it and now there are two! Thanks!)

    Copy & paste the code below to embed this comment.
  47. Jon, that’s right. It’s a contradiction I can’t resolve either.

    Copy & paste the code below to embed this comment.
  48. I don’t know if another post is going to help this, but let me try this again. First there’s confusion between semantic languages and presentation. Nothing has changed in the W3C semantic recommendations regarding the “˜q’ element (even in the draft XHTML 2.0 recommendation). The recommendation is that authors should leave off quotation marks and use the semantic markup of the “˜q’ element instead. The presentation is then handled by CSS (either through the browser’s default stylesheet or through an author or user style sheet). The second point I was trying to make that has failed to clear up the confusion is that quotation marks are not like other punctuation. They are one of the ways quotations are presented. The other way quotations are often presented is as an indented block (particularly when the quotation goes beyond a certain length). I”˜m not talking about different languages here, I’m saying in English in the same document quotations get presented in two different ways. These are the sorts of decisions that are best left to the publshing-time through style sheets and not hard-coded ito the semantics of the document. So having a semantic construct like the “˜q’ element is far superior in my view than hard-coding presentation into the document. When asking why should the author leave quotations up to the software, that’s a red herring question. The author is not leaving quotations up to the software. The author is authoring semantics in the semantic markup (HTML, XHTML, etc) and authroing presentation in the presentation portion of the software (CSS, XSLT, etc).

    I don’t have easy access to JAWS, so I cannot test whether it responds to CSS directivves like the voice-family or pause properties. Again like IE, why do users and authors tolerate such poor software. Switching voices by CSS selector would be just as simple as adding generated content before and after the element for IE.

    Also, it’s a bit of an exaggeration to say the aural CSS has been deprecated. The speech media type is largely a renaming of the aural media type. What is being deprecated there (as part of this renaming) are a few properties that were aural but didn’t relate just to speech (like aziumth). All of the speech related properties from CSS2 remain in the draft CSS3.

    Let me finish by saying I think the conditional comment approach mentioned by Ian Oxley in post #56:

    e.g. Did you know <!—[if IE]>“<![endif]—><q>The quick brown fox jumps over the lazy dog</q><!—[if IE]>”<![endif]—> contains every letter of the alphabet?

    The problem is that IE will not then participate in the separation of semantics from style that the W3C standards make possible. But that”?s true of many iof the other obsolete browsers as well. It’s merely another sign of the contempt Microsoft shows for its customers.

    Copy & paste the code below to embed this comment.
  49. http://www.cs.cornell.edu/Info/People/raman/emacspeak/emacspeak.html

    Copy & paste the code below to embed this comment.
  50. Looking over this conversation again I think aother source of confusion is two separate issues with IE. One (the more serious IMHO) is that it doesn’t support CSS generated content and the associated “˜:before’ and “˜:after’ pseudo-selectors. The second is that id didn’t support the automatic inclusion of quotation marks around the “˜q’ element. The second one is no longer important beacus it has been superceded by the CSS specification. If IE only handled CSS properly this would not be an issue for anyone. Authors who didn’t want to pursue a strict separation of semantics and style could do so by entering quotation marks in their HTML and not in their CSS. Those who wanted to separate semantics and style could enter quotation marks in the stsyle sheet and leave them off ot he HTML. We’d have a choice. Instead we have a MS pain in the ass.

    This is what’s depicted in the XHTML2 draft examples. Doing it either way. However, that’s clearly based on the hope that IE either begins to support CSS generated content or that it continues its decline in popularity.

    Copy & paste the code below to embed this comment.
  51. Quotation marks are part of the structure of a page, just like exclamation marks, question marks, capital letters and full stops. They add structure, and therefore meaning, to the text.

    The TEI documentation has some useful discussion around “marking up highlighted text”:http://www.tei-c.org/Lite/U5-hilites.html which goes either way for marking up quotations.

    The “XHTML 2.0 recommendation”:http://www.w3.org/TR/xhtml2/mod-text.html#sec_9.8. says:

    Visual user agents must not by default add delimiting quotation marks (as was the case for the q element in earlier versions of XHTML and HTML). It is the responsibility of the document author to add any required quotation marks, either directly in the text, or via a style sheet.

    Nothing to do with IE. Everything to do with the fact that the quotation marks may be important to the structure of the document.

    Copy & paste the code below to embed this comment.
  52. What would we do without Wikipedia? There are “corner brackets”:http://en.wikipedia.org/wiki/Quotation_mark#Corner_brackets_in_East_Asian_languages in Chinese and Japanese, or think of “quotation dashes”:http://en.wikipedia.org/wiki/Quotation_mark#Quotation_dash common in literature. Automatic quotation marks inserted by the browser don’t make any sense at all.

    Copy & paste the code below to embed this comment.
  53. No one is advocating browsers automatically inserting quotation marks. No browser does this anymore. Back in the 1990’s they did. Every browser I am familiar with except for IE now supports CSS generated content and allows authors to use that for quotation marks. IE alone flouts this recommendation and thus creates this controversy.

    Copy & paste the code below to embed this comment.
  54. 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?

    Copy & paste the code below to embed this comment.
  55. 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.

    Copy & paste the code below to embed this comment.
  56. 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.

    Copy & paste the code below to embed this comment.
  57. 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.

    Copy & paste the code below to embed this comment.
  58. By the way, if anyone wants a good resource on marking up the semantics of quotations in electronic texts, I can recommend “quotations”:http://www.tei-c.org/P4X/CO.html#COHQQ from “Elements available in all TEI documents”:http://www.tei-c.org/P4X/CO.html

    Copy & paste the code below to embed this comment.
  59. 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.

    Copy & paste the code below to embed this comment.
  60. 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.

    Copy & paste the code below to embed this comment.
  61. 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?

    Copy & paste the code below to embed this comment.
  62. 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.

    Copy & paste the code below to embed this comment.
  63. 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.

    Copy & paste the code below to embed this comment.
  64. Rob, I think you are missing the point.

    My personal opinion is that quotation marks should not be added by the browser as is required by the W3C recommendations, and that their addition by browsers rather than the author of the content could in fact be to the detriment of accessibility. Besides, to my mind, quotation marks are part of the content and not presentational information to be left to CSS.

    Yes, it is unfortunate that Internet Explorer doesn’t support certain things, but that wasn’t the focus of what I have been saying. And I am not trying to justify anything about Internet Explorer. The point I rasied was about whether or not control over punctuation should be with the browser at all. The fact that browsers (except IE) allow you to control the delimiting quotation marks that they add via CSS is pretty much irrelevant to that discussion. If you turn off CSS, the browser’s default styles will still be active and the delimiting quotation marks they add will still be there. CSS rules you add will not fix the fact that the browser has control over your punctuation – your content.

    And for the record, I find it unfortunate that you have felt it necessary to descend into rudeness – I will not waste my time replying to you if it continues. If you have a point, I suggest that you collect your ideas into a coherent post before hitting the submit button.

    Copy & paste the code below to embed this comment.
  65. Another option: leave the good browsers’ generated content alone (cool idea though), and hack IE.

    [removed]
    function fixquotes(e)
    {
      if (e[removed].substring(0,1).search(/”/) -1) e[removed] = ‘“’ + e[removed];
      if (e[removed].substring(e[removed].length-1,e[removed].length).search(/”/) -1) e[removed] = e[removed] + ‘“’;
    }
    [removed]
    <style type=“text/css”>
    q {fixquotes:[removed]fixquotes(this));}
    </style>

    …Good for developers who are in those jobs with high-paying corporate clients, but want to stay as close to semantics as possible.

    Copy & paste the code below to embed this comment.
  66. Hence only IE support it.

    Copy & paste the code below to embed this comment.
  67. I tend to use straight quotes instead of using css to needlessly complexify your content to that degree. I’m sure that has been said by others in all of these pages of comments.

    It may offend one’s web 2.0/css sensitivities, but it’s easy, simple, and takes no time to do a search-replace.

    Copy & paste the code below to embed this comment.