Long Live the Q Tag

107 Reader Comments

1. It’s worth noting the XHTML 2 spec (working draft) calls for browsers to *not* render quotes around Q tags.

   bq. 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.

   From: http://www.w3.org/TR/xhtml2/mod-text.html#sec_9.8.

   I’m looking forward to the BLOCKCODE and L tags, myself.

2. Hi. In the code examples in the article, the HTML entities are incorrectly being shown. For example, this is what it should show:

   @Did you know &ldquo;<q>The quick brown fox jumps over the lazy dog</q>&rdquo; contains every letter of the alphabet?@

   But, instead, it should be:

   @Did you know “<q>The quick brown fox jumps over the lazy dog</q>” contains every letter of the alphabet?@

   The @”@ et al examples area also being displayed like so @&rdquo;@, which is, of course, incorrect.

   (That is, it’s not what the writer intended, as the entities used within writing the essay for displaying the @@ tags are also dispalys as @<q>@.)

   M.T.

3. See, it just happened to that post as well. It’s HTML Identifying the content inside of the tags as well. (That is, those of which that are being wrapped in the at sign (@).)

   M.T.

4. As soon as you still need to ï¬?x quotes to their correct entities it is sounds as a good point to actually redeï¬?ne these quotes or put them in HTML as it was suggested. Also take into account that different languages using different quotes (sometimes), so you can’t really rely on browser.
   I think that web, including really modern browsers, is not really grown up for Q tag yet. IE just the worst, but neither of others is good.

5. If your pages are being processed by the server each time they’re accessed (perhaps by a templating engine), you may be able to write some simple code to transform tags when the visiting browser is IE. I use this approach on one of my sites—it substitutes &ldquo; and &rdquo; for and , but only if the User-Agent header claims to be IE. Browsers that can handle get it, and IE gets a slightly degraded but correctly-rendered version.

6. Looks like there’s a bug in the preview–it processes HTML entities when the server’s code doesn’t. The second sentence should read:

   bq. I use this approach on one of my sites–it substitutes “ and ” for and , but only if the User-Agent header claims to be IE.

7. I’ve been using this solution for a while. I’m not too keen on it though. It essentially removes good rendering behaviour from good browsers in order to facilitate bad mark-up behaviour by authors to accommodate bad rendering behaviour by buggy and soon-to-be-obselete browsers.

   I recognise the JavaScript solution doesn’t deal with IE(Internet Explorer) lte(less than or equal to) 6 users who have scripting disabled, but that will be a shrinking population once IE(Internet Explorer) 7 comes out.

   So, I say add a script element between your conditional comments, and take it out when IE(Internet Explorer) 6 finally dies out.

   http://juicystudio.com/article/fixing-ie-quotes.php

8. I ran through your example and found it did indeed display correctly, great!

   Until of course I viewed the page in a text browser and found the quotation marks were being displayed twice.

   This is because obviously there is no CSS support in text browsers and without CSS support you cannot hide the text browsers default style for the Q tag which is to show quotation marks.

   Any suggestions yet on getting around the lack of CSS support?

9. I’ve spent ages trying to argue with people that the way to do it most effectively was to tell the other browsers not to add quotes from CSS and then manually put them in, and _finally_ someone agrees – and whats more, gets it published on ALA.

   Well done, Stacey!

   Of course, there is one flaw: any browsers which render quotation marks around by default but *do not* support css will end up with two sets of quotation marks. But frankly as this is likely to be well under 1% of any audience, you’re better off catering to IE’s much bigger market share.

10. Paul Waite: “It essentially removes good rendering behaviour from good browsers in order to facilitate bad mark-up behaviour by authors to accommodate bad rendering behaviour by buggy and soon-to-be-obselete browsers.”

    If only this were true! IE7 doesn’t support the q tag either, and (much as may wish it weren’t so) will soon be the majority browser.

    What meaning does <q> confer that a quotation mark doesn’t? I’m not an expert on screenreaders, but I’d bet they all say the same thing when they encounter an open q tag as they do when they encounter an &ldquo; or a &quot;.

    Sadly, when it’s come to a hack like this – which, I have to say, doesn’t even fix the problem – it’s time to drop the dream of smart quotation marks in HTML; pausing to notice the many other scraps of meaning not conferred by hypertext markup: proper nouns, geographical locations, recipes, … ; and get on with our lives.

11. I don’t see why we should remove the quotes from all other browsers to get it in IE working. If you see your solution (and as I just have discovered in the first comment to this post: Also in XHTML 2) from the semantic side, you get the quotation marks as part of a text, which is not right.
    Here is an example of what I mean:

    Did you know &ldquo;<q>The quick brown fox jumps over the lazy dog</q>&rdquo; contains every letter of the alphabet?

    If you break this down you get these parts:
    # Normal text: Did you know &ldquo;
    # Quote: The quick brown fox jumps over the lazy dog
    # Normal text: rdquo; contains every letter of the alphabet?

    So we get a correct quote (without the quotation marks), but two parts of text that have quotation marks in it. If I see the “semantic” as a part of efford making computer programs help to understand websites, I have two quotation marks that make no sense:
    From a program point of view, they are a part of the paragraph. So if you cut the <q> out you still have the quotation marks which are now indicating what?

12. Chris Ovenden: “What meaning does confer that a quotation mark doesn’t?”

    It is supposed to adhere to locale-settings. E.g. There are different quotation-marks in norwegian than in english. So when is descendant of an element which, or it self does containt a lang-attribute it is supposed to render the correct quotation marks.

13. Michael, what you describe is functionality, not meaning. A pair of quotation marks has the same meaning as a pair of q tags – what’s inside is a quotation – although, as you say, one is locale-specific. Should we introduce a tag that surrounds all questions, so that, say, in a Spanish locale the upside-down question mark appears at the beginning of the line? Perhaps, but it’s a forlorn hope.

    It would be lovely if q did what it was supposed to do in all browsers, but it doesn’t. And – given that it will continue to wither for the lifecycle of IE7 – it probably never will.

14. Me parece una solución tan “genial” como “semántica”. La fuerza de la etiqueta “q” es indudable, y no tener que implementar más marcado es siempre de agradecer. Brillante.

15. A tag is meant for quotations only, whereas a quotation mark has multiple uses like slang words, technical terms or a title of a book.

    A screenreader could then do things like read the tag in a different voice since it knows for sure that it is dealing with a quotation.

16. If user disables CSS, or uses device that does not support CSS, she will se double quotes, right?

17. IE apparently will support generated content in later releases. Then what happens?

    I thought of a wacky solution. No flames please. How about defining the quotation marks as a tiny image and adding them to the Q tag that way? It would work for the start of the tag (by using padding), but I’m not sure how to do the end of the tag, without using generated content for IE6 and below, which doesn’t support that.

18. I have a large quarrel with this article: it assumes that the people using IE with disabled javascript outweighs, or rather, is more important, than those who use screen readers or text browsers because they have low vision or are blind. I can’t imagine how hard it must be already to get information on the web using a screen reader, but this would definitely just start making it more difficult.

19. I must admit, to my chagrin, that in all my years, I haven’t even heard of the tag until I read Head First HTML with CSS & XHTML by Elisabeth Freeman & Eric Freeman. I don’t even think Lynda’s (Lynda Weinman) famous HTML book mentioned it. I’ve always used &ldquo and &rdquo. My question is, that if that works, why bother with a tag that doesn’t? It seems like overkill to try to force recognition of a tag that doesn’t function properly.

20. Isn’t this approach an example of “5. Using the Q tag, but also including your own quotation marks.” – one of the solutions you said you didn’t want to use?

    I think – if I could be bothered – I’d use an IE-only stylesheet to make q elements italic, and an IE-only script to insert the quote marks and turn the font-style back to normal. That way, the only people who don’t see the quotes are Javascript-off IE users, who get italics instead (which is very far from ideal, but still better than nothing).

    Having said that, I use so few inline quotations that it’s really not worth the effort of trying to make q elements work properly. I just sigh and type in plain quotes.

    If a practical application ever emerges which actually _uses_ q elements for something, I may reconsider. While it’s just “semantic web” vapourware I’m not losing any sleep over it.

21. I think it’s worth noting that if you copy and paste text from a page that uses Q (by itself), no quotes are inserted into the copied text. That makes the Q tag somewhat useless in a semantic regard. (Tested in Firefox and Safari.)

22. Very well-written. This is a clever solution, barring the potential problems noted. I also like the server-side solution that Brent Royal-Gordon suggested.

    One possible issue with the author’s solution is if IE supports the :before/:after pseudo elements before providing support for Q, or vice-versa, one would have to go back to re-address the matter on X-number of sites.

    Regarding the server side solution, it may be necessary to specify IE versions down the road if Q support is someday provided. If one is prepared to go back and modify the scripting at some point — which would be needed as we never really know what Microsoft is going to do and thus we can’t address this ahead of time — then this might be a safest and easiest to manage solution.

    In any case, very nice article.

23. Personally I love the Q tags and I use them often when writing for the web. Apart from having a meaning for any web-browsing software, including screen-readers and spiders, apart from adapting to locale, it has one more feature that is very important for me:

    Q tags can be styled with CSS.

    Sure, I can use

    Seems like <, > and & are escaped twice when posting the message. Could maybe somebody fix it?

24. Just pointing out here that your solution suffers from the same thing you point out as a flaw in the JS solution…

    _Double quotation marks will appear if and when IE/Win fixes the problem in a future release._

    Unless you’re assuming that at the same time, support for the :before and :after pseudo-elements will also be fixed.

25. I’ve read that things are moving toward @quote@ instead of @q@, is that right? I’ve been using @quote@ partly for that reason and partly because I prefer to control quotation marks myself. It seems like that’s akin to a period, comma, or other punctuation and I hate to let a browser decide if/when/how it wants to display punctuation – which is essentially content, right?

    I’m glad to see someone writing about this again though. It’s tough enough just getting people to stop using @blockquote@ for indentation, so @q@ or @quote@ doesn’t matter much right this moment. 🙂

26. Chris Botman points out the “XHTML2 specs”:http://www.w3.org/TR/xhtml2/mod-text.html#edef_text_q for the element. These specs are obviously not set in stone, but shouldn’t we keep an eye toward them for forward compatibility?

    As Chris points out, browsers will _not_ render quotation marks by default in XHTML2. So the solution that Stacey provides here is in fact perfect, since it encourages us all to start coding quotes correctly now.

    Note, however, that the XHTML2 spec (at least in the example the W3C provides) encourages quotation marks to fall inside the tag, even allowing for quotes within quotes, as follows:

    bq.

    John said, “I saw Lucy at lunch, she told me
    ‘Mary wants you to get some ice cream on your way home.’ I think I will get some at Jen and Berry’s, on Gloucester Road.”

    So the conclusion if applying this technique, I presume, would be to include your own quotation marks and put them within the tags.

27. I wrote “a similar article”:http://www.whatstyle.net/articles/styling_quotations/ and totally agree with the author.

    Although in the comments on my article some interesting links are posted that point to problems caused by this technique.

28. This really seems like a solution in search of a problem to me. Why not just use actual quotation marks, and maybe a if you really want to style the quotes differently?

    I’m sure there are some good reasons, probably involving accessibility, to use tags, but this article doesn’t provide any of them, which leaves me wondering why anyone would ever use the technique described in it. Next time Stacey, try explaining what your technique actually achieves before describing how to implement it.

29. For those who support italicizing the q tag to give it some sort of style, what else do you suggest be done for the tag if it was inside an inline level element that was already italicized? Sure, it’s easy to know you need to come up with something different for descendants of the em or i tags, but I’m sure anyone here can think of another example where it would be unexpected to know that this would happen ahead of time. What other style rules should be applied? This is why there is a need for user agents to support the auto-quote styling. It removes the ambiguity.

30. Because I’m going to be very critical afterwards, I’d like to begin by thanking Stacey Cordoni for sharing her technique with us. The more ideas are bounced around, the better for all of us.

    Cordoni is mistaken to imply that this is an IE-only problem. Q is partially implemented by most user agents, but fully implemented by none. There is no language-sensitive implementation. The current version of ELinks will display Q in cyan in 16 color mode but does not differentiate Q in monochrome or 256-color mode.

    I share the author’s commitment to “semantic markup” and her concern for “accessibility”, and empathize with her quixotic desire for “consistent visual display”. But her proposed solution, which provides none of these things, made me want to tear my hair out. Let me explain why:

    1. The semantics of (X)HTML are defined by W3C specifications. Violating those specifications in order to create a “consistent visual display” is the exact opposite of writing “semantic markup”.

    bq. &ldquo;The quick brown fox jumps over the lazy dog&rdquo;

    is not a quotation, but (if anything) a quotation of a quotation.

    2. The display from this technique is not consistent, since quotation marks are doubled when CSS is unsupported, disabled, or overridden.

    3. This proposal offers no clear accessibility benefit. Yes, if you have Window-Eyes you can configure it to announce the beginning and end of quotations. Yes, if you use EmacSpeak with the extinct Emacs/W3 browser, or Opera, you (or the page author) could apply an aural stylesheet to Q. But has anyone succeeded in configuring any other screen reader to use Q effectively? I’ve failed miserably with Jaws 7.10 and Hal (so far). So sophisticated screen readers may double the punctuation, while crude screen readers gain no benefit from Q’s presence. Some screen readers will read Q in the correct language following its “lang” attribute; but then a SPAN has exactly the same functionality.

    Here’s an alternative suggestion that does not explicitly break the W3C specification, is displayed the same in all browsers, can be styled with aural CSS, and can be read in its proper language:

    &#8216;Bonjour!&#8217;

    If you want to use Q, you’ll need to accept that some users may not be able to distinguish your quotations from the surrounding text. Rather than compromising your markup with the solution given here, I would strongly suggest supporting IE/Win users with conditional comments, either adding the quotation marks directly into the text, or styling with italics, or adding punctuation with JS (or some combination thereof).

    Having said all that, I like very much the idea of the Q element. My personal view is that since punctuation can alter the meaning of quoted material, semantic markup (Q, INS, DEL, BLOCKQUOTE) offers a chance to disambiguate quotation and interpolation. Traditional typography has often obscured this basic information. For example, whereas US English typically brings commas and full points following quotations within the quotation marks, British English typically only does so if that punctuation is present in the quoted material. As The Oxford Guide to Style (2002) comments: “While this does not vex Americans very much, the ambiguity can cause editorial problems when transforming American text and transposing closing punctuation.” It can become a tremendous hassle for scholars if quoted material is lost or otherwise unavailable.

    This potential for Q and BLOCKQUOTE seems to have been lost on most advocates of quotation markup, including W3C’s own web accessibility WG, who included a citation *inside* a BLOCKQUOTE in a “horrendous example of techniques for WCAG”:http://www.w3.org/TR/WCAG10-HTML-TECHS/#text-quotes .

    If you want to encourage the proper use of Q, I recommend you:

    A) Do *not* add to the chaos by using the technique advanced by this article.

    B) If you know how to make a user agent utilize the Q element, whether with configuration, a Jaws script, a LISP file, whatever, share that knowledge. For example, with Window-Eyes 5.5, select “Verbosity…” from the menu, then “Browse Mode”, then “Quotes / Block Quotes”. Tick “Insert Beginning / End Message”. Now Window-Eyes will announce the beginning and end of Q.

    B) Encourage W3C to create a “workable specification of Q and associated style properties”:http://lists.w3.org/Archives/Public/www-style/2006Sep/0141.html for (X)HTML+CSS.

    C) “Help those who write developer documentation like MSDN to describe the Q element correctly”:http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=745161&SiteID=1 [microsoft.com].

    D) Join the (free) “Internet Explorer feedback program”:https://connect.microsoft.com/IE and vote for “Feedback ID 56347”:https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=56347 [link only works once signed in]: “Q elements don’t insert quote marks (determined by CSS/language)”. The IE team have not ruled out fixing this behavior in the next release after IE7.

    F) Design XSLT, CSS, or JavaScript algorithms to punctuate Q correctly according to the complicated typographical rules propounded by guides like the Chicago Manual of Style, and make them available to the world (note: once you limit the content of Q to content that was actually in the source material, this task becomes rather complicated).

    G) Encourage Freedom Scientific and other screen reader developers to provide support for Q, and better yet make such support default behavior.

    H) Work on improving the default rendering of Q so that it is sensitive to nesting and language, as per the W3C specifications, in Firefox (“Mozilla Bugzilla 354356”:https://bugzilla.mozilla.org/show_bug.cgi?id=354356 ), Lynx, ELinks, Opera, WebKit, KHTML, and {insert your favorite browser here}.

    I) Work on fixing other browser bugs, like the failure to copy to clipboard generated content as “mentioned by Justin Greer”:http://alistapart.com/comments/qtag?page=3#22 . There may be similar issues with the GoogleBot, but I haven’t looked into that.

    J) More contentiously, don’t pollute the semantics of Q and BLOCKQUOTE by including material that was not originally part of the source. If you need to do so, I suggest using INS or DEL.

    Just to pick up a couple loose ends:

    “Natalie Jost”:http://alistapart.com/comments/qtag?page=3#22 :

    bq. I’ve read that things are moving toward quote instead of q, is that right? I’ve been using quote partly for that reason and partly because I prefer to control quotation marks myself. It seems like that’s akin to a period, comma, or other punctuation and I hate to let a browser decide if/when/how it wants to display punctuation — which is essentially content, right?”

    AFAIK “quote” is invalid (X)HTML; and even the current XHTML 2 draft uses “q” not “quote”. I seem to remember there was a brief period when XHTML 2 did call it “quote”; perhaps that is what you are thinking of.

    “Jim Dalton”:http://alistapart.com/comments/qtag?page=3#27 :

    bq. [B]rowsers will not render quotation marks by default in XHTML2. So the solution that Stacey provides here is in fact perfect, since it encourages us all to start coding quotes correctly now.

    I strongly disagree. You’re coding HTML 4.01 or XHTML 1.x, and you’re coding it *wrong*. Nothing that ever happens with XHTML 2 will ever make up your markup correct.

31. Why not use conditional comments and IE Javascript Behaviors to alter how q elements are rendered?

32. bq. One possible issue with the author’s solution is if IE supports the :before/:after pseudo elements before providing support for Q, or vice-versa, one would have to go back to re-address the matter on X-number of sites.

    I don’t know that it would be a problem if it’s that way round. If IE7 does support generated content on :before and :after, then it will simply add nothing at the beginning of and nothing at the end, so it won’t make any difference.

    The other way round _would_ be a problem, inasmuch as it would result in double quotes appearing. I can’t think of an easy solution to that, other than doing some serious damage to Redmond!

33. > “IE7 doesn’t support the q tag either”

    Whoops, my bad. Sorry, and thanks to Chris for the correction.

    I’d personally still use JavaScript for IE 7 and below (as my fuzzy memory is telling me IE 7 doesn’t support generated content).

34. What do you mean, the “q” start tag, or the “q” end tag? Seriously, what about correct terminology. Guess you wanted to talk about the “q” element.

    (Saying it this way because just recently, many – including me – once again pointed out the difference between elements and tags.)

35. bq. I think it’s worth noting that if you copy and paste text from a page that uses Q (by itself), no quotes are inserted into the copied text. That makes the Q tag somewhat useless in a semantic regard. (Tested in Firefox and Safari.)

    Actually, it worked fine copying from Safari and pasting into a TextEdit document. In fact, it corrected the double-hash marks to a true open and close quote.

    bq. What do you mean, the “q”? start tag, or the “q”? end tag? Seriously, what about correct terminology. Guess you wanted to talk about the “q”? element.

    Actually, it is the q start tag and q end tag. The tags plus the contents, collectively are the q element. Syntactically, that was correct. “See this”:http://en.wikipedia.org/wiki/Image:HTML_element_structure.png

36. Oops. I see Jens original point. The article title was “The Q Tag” and that was syntactically incorrect. Based on his comment, I took what he was obtusely saying as a literal quote from the article. My bad.

37. p. I’ll try to answer most of what’s been questioned or debated.

    p. *Chris Botman:* Thank you for noting that relevant information. Jim Dalton touches on this in “comment #28 (Link to comment #28)”:http://www.alistapart.com/comments/qtag?page=3#28. Like Jim says, this fix encourages web authors to start using quotation mark entities with use of the Q element. Since including the quotation marks will most likely be expected by the author in XHTML 2, this fix works well in that direction.

    p. *Brent Royal-Gordon:* A server-side solution can definitely be implemented. One like you mention, however, being as it removes the Q tags entirely from IE, will cause unsemantic markup. Likewise, since JAWS is designed for use in IE, it will also pose an accessibility issue. Once the page is processed and the Q tags are replaced with quotation marks, JAWS will no longer recognize that as a quote.

    p. *Paul:* How ironic I didn’t find that article on my many scavenges for articles related to the Q element. I did write my first draft on July 15th though, and I see that one was published in August, so that’s why. Originally I came up with this idea on the “DevShed Forums (Link to the DevShed Forums)”:http://forums.devshed.com and I know that an avid poster, “Gary Turner (Link to Gary Turner’s Website)”:http://garyblue.port5.com/, posted an “article (Link to ‘What you need to know about quotes in the HTML page’ by Gary Turner)”:http://garyblue.port5.com/webdev/quotes.html of my findings on his web page soon thereafter and then it seems the idea started popping up here and there before my publication date on ALA.

    p. Like Chris Ovenden mentions in “comment #11 (Link to comment #11)”:http://www.alistapart.com/comments/qtag?page=2#11, and as I mentioned in the article, IE7 most likely won’t support the Q element either. Not to mention, I would beg to differ that IE6 is a soon-to-be-obsolete browser, even when IE7 is released.

    p. *Mark:* Yes, double quotation marks do appear in text-only browsers, browsers with CSS turned off, or if the CSS is overridden. Personally, I accept the double quotation marks in text-only browsers if it means my IE users get to see quotation marks (with still adhering to semantic markup and accessibility.) Not to mention, the number of people using IE versus text-only browsers is hugely significant.

    p. *Jack:* It seems the Q element will be a never ending dispute by many, but I’m hoping to shed some insight on a simple solution – although not perfect, I believe it’s definitely worth using and I’m glad you agree.

    p. *Chris Ovenden:* The Q element is neccessary for semantically correct markup and is also neccessary for screen readers. Screen readers _do_ react differently to an open Q tag than to a left quotation mark. Also, quotation marks have many uses, they are not just used for quotations. Like Adrian D mentions in “comment #16 (Link to comment #16)”:http://www.alistapart.com/comments/qtag?page=2#16, quotation marks can be used for slang words, technical terms, book titles, song titles, etc.

    p. How does this CSS hack not solve the problem? This fix does work – with a minor fall back of double quotation marks in text-only browsers, browsers with CSS turned off, or if the CSS is overridden.

    p. *Paul Armstrong:* I must say I’m a bit confused with your comment. If you read the article correctly (and completely), you will have known that this fix works with screen readers as well as with JavaScript disabled browsers.

    p. *Al Lemieux:* The Q element is neccessary for semantically correct markup and for screen readers.

    p. *Chris Hunt:* My solution is to surround the Q tags with quotation mark entities and include a short CSS hack to remove the quotation marks set by the users browser. In my article, example number 5 does not mention anything about the CSS hack – so no, it is not one of the solutions I suggested not to use.

    p. *Mike Cherim:* Thank you. Actually, if IE ever supports the :before/:after pseudo elements before providing support for the Q element, the fix still works. IE will act as the other browsers act now. However, you are right, if the Q element is supported before the :before/:after pseudo elements, double quotation marks will appear. According to the “IEBlog (Link to the IEBlog)”:http://blogs.msdn.com/ie/, neither are yet on the agenda for being supported in IE7.

    p. *Steven Paulo:* Yes, you are correct. No one knows when or which will be supported first, and I didn’t want to hold this article back until then because it’s quite useful now (and will be for some time since neither the Q element or :before/:after pseudo elements are currently on the agenda to be supported by IE7).

    p. *Brian LePore:* Good Point.

    p. *Benjamin Hawkes-Lewis:* First off, Thank you. You make some very valid points. Some of what was mentioned comes down to personal preference though. Every web author has different priorities and as written in the article, this fix works best for me and my priorities (and probably a bunch of other persons). I do not believe this technique is “chaotic” as you put it, nor do I believe including the quotation mark entities should be defined as polluting the semantics of the Q tag. A lot of what you list people to do is advocate for support of the element and other such things. Once supported, that’s all fine and dandy, but people still browsing with older browsers will have the same issue as we have now. Even when IE decides to support the Q element, this fix will still work and should be used until the older browsers are obsolete.

    p. *Josh Peters:* I never said you couldn’t. As I mentioned in my article, I suggest a JavaScript fix to be a great secondary solution.

38. Stacey Cordoni observes:

    bq. Likewise, since JAWS is designed for use in IE, it will also pose an accessibility issue. Once the page is processed and the Q tags are replaced with quotation marks, JAWS will no longer recognize that as a quote.

    Jaws 7.10 supports Firefox 1.5 too. But other than the “lang” attribute, how did you coax Jaws into announcing Q or using a different voice for Q? Like I say, I’ve failed miserably at that.

    bq. Screen readers do react differently to an open Q tag than to a left quotation mark.

    Which other screen readers, and in what configuration, are you talking about here?

    bq. people still browsing with older browsers will have the same issue as we have now

    If people serve XHTML 1.x, they should use application/xhtml+xml (see “Ian Hickson’s arguments”:http://www.hixie.ch/advocacy/xhtml and “W3C’s note”:http://www.w3.org/TR/xhtml-media-types/ ); 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.

    The XHTML 2.0 draft currently says that quotation punctuation should be added in the text or the stylesheet, and some punctuation cannot be added without CSS. If people start serving application/xhtml+xml, older browsers will need to be served HTML for the same resources. If we develop the algorithms to add quotation punctuation to Q now, we will be able to serve styled Q to XHTML browsers and serve in-text quotation punctuation around SPAN to HTML browsers. (Indeed we could be doing that already, but XHTML currently adds little advantage over HTML 4.01 unless you’re using SVG or MathML.)

    bq. I do not believe this technique is “chaotic”? as you put it

    I should probably have explained that in addition to its failure to achieve its stated objectives (IMHO), it makes the task of parsing and representing web documents (even more) hopeless, since you do not declare whether you are using the Q element the way the specification says you must, or the way you would prefer. If people start using this technique, how are screen readers supposed to react to Q and quotation punctuation? If they announce Q *and* read punctuation, that will work great for people who have used Q as per the specification; but users will have to listen to both on pages using your technique. But if they do not read punctuation then users will not know what is a quotation on most web pages, which do not use Q at all. So your technique actually reduces the already small incentive screen reader developers have to support Q. The very existence of this article, let alone the use of the technique, contributes to the wholesale confusion about Q (e.g. on MSDN) that I for one have been trying to combat. This is why I think it *adds* to the chaos that is already out there.

    bq. nor do I believe including the quotation mark entities should be defined as polluting the semantics of the Q tag.

    Just to clarify a little, my line about pollution was not referring to your technique, but to people placing content or punctuation inside the Q element that was not in the source material. (The example currently serving for the XHTML 2 draft is another example of such pollution. I hope to get that changed.)

    But I would argue that your technique corrupts your markup. What do you think quotation punctuation means? What do you think the Q element means? Now what do you think it means when you put them together? I think it means (if anything) a quotation in a quotation, or maybe a quotation in an article title.

    If you do not wish to use HTML as per the specification, perhaps you should define a custom DTD, explain how user agents should treat documents of that type, and employ that for your documents instead. That way user agents and automated agents can know for certain how to interpret Q. Such practice is supported under the umbrella of “RFC 2854”:http://rfc.sunsite.dk/rfc/rfc2854.html . If you balk at that, perhaps you can come up with a metadata profile or something for HTML that will at least signal that you’re using Q incorrectly.

39. Firstly I’d like to congratulate Benjamin Hawkes-Lewis for his well-written and intellectual posts. Secondly, in response to Stacey Cordoni’s comment _”…quotation marks can be used for slang words, technical terms, book titles, song titles, etc.”_ isn’t the CITE tag meant for titles, and the DEF tag meant for technical terms? Let’s not forget the VAR tag too when dealing with code. Otherwise a SPAN is the best bet.

40. Oops, I meant the DFN tag there.

41. Firefox sometimes miscalculates the width needed for a quoted text 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*;
    }

42. 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; }

43. 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?

    Yeah!

    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.

44. 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 ? 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.

45. bq. 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?

46. 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.

47. bq. 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.)

48. 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.

49. The element, which “Contains a citation or a reference to other sources,” is better for titles of books than the element. Book titles in English are usually in italics, not quotation marks. Of course, you’d need to make s italic in your style sheet, but they’re more accurate than 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

50. bq. 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 tag. There’s some discussion here, including a test with JAWS in Firefox and IE:
    http://accessifyforum.com/viewtopic.php?t=6256

51. 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 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).

52. Would it be simpler to just add quotes within conditional comments for IE/Win

    e.g. Did you know The quick brown fox jumps over the lazy dog contains every letter of the alphabet?

53. bq. 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.)

54. Jim,

    If JAWS and other screenreaders don’t use the 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 markup?

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

55. bq. If JAWS and other screenreaders don’t use the 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 , , , and all those other wierd little inline phrase elements. You might want to style inline quotes with CSS, for example. would give you a markup hook to use for that.

56. PS Can someone change this line in the original article

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

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

57. bq. Does anyone know of any browser, application or utility that actually makes use of the markup?

    My tests that Jim linked to are very simple. I haven’t yet had time to investigate further. However, it seems that the 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 elements available to assistive software (in the same way that IE doesn’t support ) I don’t hold much hope for other screen readers.

    bq. It seems to me that if the XHTML2 spec requires that UAs not add quotes to 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 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 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 element. At least until I’m satisfied with an approach which stops user agents doubling up the quotation marks I use.

58. Jim Dalton said:

    bq. Chris Botman points out the XHTML2 specs for the 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.

59. 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.

60. 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.

61. The more, the merrier!

62. bq. but this degree of hostility’s a bit uncalled for.

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

63. 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:

    # rely on the default rendering of quotes in standards-compliant browsers;
    # 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)
    # 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 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!

64. 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.

65. _”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.

66. Jeffrey Zeldman said:

    bq. 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 element. As someone else pointed out, the article unequivocally contradicts the existing XHTML1/HTML4 spec for :

    bq. 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.

67. bq. 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 🙁

68. 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.

69. 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:

    bq. 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:

    bq. 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!

70. bq. if they did, it would be easy enough…

    That is,

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

71. 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.

72. bq. 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.

73. If CSS if off, this looks quite terrible.

74. 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 (?), (!), or just regular (.)?

    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.

75. Accomodate a broken browser by breaking the ones that work?
    No thanks.

76. bq. Accomodate a broken browser by breaking the ones that work? No thanks.

    But the browsers that don’t recognise 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 tag as described in the HTML 4 spec does not. Therefore, from an accessibility point of view, Firefox and Opera are broken.

77. 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?

78. 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 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 and using proper punctuation to mark up quotes, or use the tag and the technique in this article to remove generated quote marks in Firefox and Opera.

79. bq. 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 is ruined by a badly considered recommendation, causing browser inconsistency and leaving assistive software unsure what the heck to do.

80. 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?

81. 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.

82. 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.

83. (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.

84. 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.

85. 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!)

86. Jon, that’s right. It’s a contradiction I can’t resolve either.

87. 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 “The quick brown fox jumps over the lazy dog” 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.

88. http://www.cs.cornell.edu/Info/People/raman/emacspeak/emacspeak.html

89. 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.

90. 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:

    bq. 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.

91. 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.

92. 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.

93. bq. 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?

94. 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.

95. 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.

96. 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.

97. 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

98. 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.

99. bq. 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.

    bq. 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.

    bq. 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.

100. 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?

101. 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 tags.

     Hope that clears up that bit of confusion.

102. 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.

103. 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.

104. Another option: leave the good browsers’ generated content alone (cool idea though), and hack IE.

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

105. Hence only IE support it.

106. 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.