accessibility_fail | Accessibility question

if you are just writing prose and not doing anything fancy, you should be fine. Both the dreamwidth coders and the archive of our own coders do a good job making sure those two sites are accessible to screen readers.

Using semantic markup (strong and em instead of B and I) is a good technique, but all modern screenreaders actually do fine with B and I.

Things which are unlikely to apply with fan fiction in either of those two contexts, but maybe well:

As a general rule, use CSS to do fancy layout instead of tables. Use HTML headers instead of bolded text to separate sections. Screen readers will read all the text on the page in the order it appears in the HTML source (technically in the DOM, but for the layperson the best way to imagine this is to know that screen readers will read all the text in the order it appears in the HTML source). If you use CSS to move it around on the page in interesting ways, the screen reader will be ignoring the CSS.

Don't convey important information in color or punctuation. (Many screen reader users have their configurations set to ignore punctuation or silly HTML elements such as ♥ ("hearts").) If you use images, make sure that you have meaningful alternative text for each image. What would somebody want to know about this image if they couldn't see it? Don't use the TITLE attribute to convey information that is not conveyed somewhere else as well; this will be invisible to most screenreader and keyboard-only users.

If you do anything fancy with JavaScript, make sure you have talked to somebody about how to make sure it is accessible to both keyboard-only and screenreader users.

If you are on Windows, you can install NVDA, an open source screen reader, to get some idea from a beginners point of view what the process is like.

.
Thank you. As you say, for stories, most of those won't apply. No tables for example, though I'll need to learn the alt tag (?) to describe pictures in a couple of stories.

Use HTML headers instead of bolded text to separate sections.

This I don't understand; can you explain further? Mostly, I don't have any 'heading' for a new section, which is why I need to know if screen-readers take notice of [hr], or if I should color-hide the words 'Section Break'.

all modern screenreaders actually do fine with B and I.

Yikes! See, for a post, I use bold and/or italics for emphasis. But for a fanfic, I use italics for thoughts also, which I wouldn't want the screen-reader to render with emphasis. I thought [i] would give a signal to the visual readers, without overloading the screen-reading listener.

In short, I'd like a way to code a difference between italics and bold that I intend for vision only, and those I intend for spoken emphasis. Is there a reliable way to do that?
.

I'll need to learn the alt tag (?) to describe pictures

The alt attribute of the img tag, as in <img src="http://www.example.com/image.jpg" alt="A white knight sitting on a horse" width="640" height="480"> (or something like that).

Use HTML headers instead of bolded text to separate sections.

This I don't understand; can you explain further?

If you have named sections (chapters, days in a diary, or the like), you can use HTML headers - <h1> to <h6> - to mark them up.

In my experience, h1 typically only occurs once; it'll be the title of the entire page. h2 is "beneath" that (chapter?), h3 even lower (section?), then h4 (subsection?) and so on. The exact meaning of each level, as well as how many levels deep you want to go, is up to you, of course. (For example, you may just need one kind of section, in which case h2 might be the way to go.)

In a visual browser, the font size typically gets smaller as you go from h1 down to h6, to mark increasingly-smaller units of text.

Edited (forgot a closing angle bracket) 2010-04-01 20:12 (UTC)

.
Thank you for the alt code; I'll save it. I can understand why the description, but is width and height necessary? Will the code fail without that information? It doesn't seem like anything a reader or listener would need to know.

I'll remember the headers code, too; thank you again. But I usually only use line-divider, such as <hr size="2" width="50%">, but I can't find anyone who knows whether or not a screen-reader makes a pause for [hr]. I've planned what to do if I need something more than [hr], but don't want to use both if it will cause a "stutter" in the reading. Have you read anything about the effectiveness (or not) of [hr]?
.

The width/height won't matter to screen readers as far as I know, but adding them is best-practice for visually-rendering browsers because it allows them to reserve space for the image on the screen before it downloads, which means the page doesn't jerk around and realign when the image finishes downloading. This is especially appreciated when the image file is large (file size, not visual display) or when there are lots of images on one page.

.
it allows them to reserve space for the image on the screen

Cool! I'm learning so much. Thank you.

Fortunately, I see that half of the "copy/paste this code to put the picture on another site" from Flickr is the <img description. I just need to change my alt from "Meeting" to "two horses in field, touching noses".

kyrielle already talked about width and height in images; I'll add that I usually add them in LiveJournal entries because some people have the option to use placeholders for images larger than a certain size (in pixels, not KB) -- and that only works if width and height are given in the HTML code (images without those attributes will always be replaced by placeholders, even if the image turns out to be 10×10, because the HTML filter can't know that).

I presume that Dreamwidth code acts similarly.

So, yeah. Rule of thumb: they're not necessary, but can be useful in some circumstances.

.
I've been experimenting in my DW. Turns out, the Flickr code includes all that (I never noticed), so I've been semi-compliant without knowing. (I load all the pics I want to show on Flickr, and use their version of "paste this code on another page".)

But Flickr's TOS ask that pics on another site lead back to the original. I assume that it's the first part of this code -

<a href="http://www.flickr.com/photos/starwatcher307/4127388572/" title="Meeting by StarWatcher307, on Flickr"><img src="http://farm3.static.flickr.com/2592/4127388572_4f25718715_m.jpg" width="240" height="171" alt="two horses in field, touching noses" /></a>

So, is the <a href part of the code still compatible with screen readers? (I would expect so, but unwarranted assumptions can kick us in the ass.)

Your earlier example showed the alt description first, with size following. Flickr has it reversed. Both versions show the correct visual image on the page but, again, will it make a difference to the screen reader?
.

Flickr's TOS ask that pics on another site lead back to the original. I assume that it's the first part of this code

Yes -- the "a" tag surrounding the "img" tag makes the image into a link.

So, is the <a href part of the code still compatible with screen readers? (I would expect so, but unwarranted assumptions can kick us in the ass.)

I would also expect so, but I have no real idea.

Your earlier example showed the alt description first, with size following. Flickr has it reversed. Both versions show the correct visual image on the page but, again, will it make a difference to the screen reader?

I would expect not -- as I understand it, attributes may occur in any order inside a tag, so any halfway-decent HTML parser should be just fine with them rearranged. (So you could even have "alt" in between "width" and "height" if you wanted.) But again, I don't know for sure.

In short, I'd like a way to code a difference between italics and bold that I intend for vision only, and those I intend for spoken emphasis. Is there a reliable way to do that?

Disclaimer: I know next to nothing about screen readers.

But if it's true that they ignore most CSS, you could use that: <span style="font-style: italic">italic text goes here</span> (or <div> instead of <span> if you want it to apply to one or more paragraphs rather than to just part of a paragraph).

.
Okay, you're talking to someone who knows only very basic code - [i, [b, [u, [p, [br and [a href. Everything else, I have to save in a cheat sheet and copy/paste when I need it. I know nothing about CSS, including what it stands for.

Now, I can copy and code <span style="font-style: italic">italic text goes here</span> (thank you for that); but that mean spoken-emphasis italics, or non-spoken-emphasis italics?

And [div] does... replaces the [span] above? Under what circumstances?

I truly appreciate the help, but I need teeny-tiny baby-explanations, if you're willing to invest the time in helping me learn.
.

Now, I can copy and code <span style="font-style: italic">italic text goes here</span> (thank you for that); but that mean spoken-emphasis italics, or non-spoken-emphasis italics?

It means just "format this text as italics"; "span" is a tag that has no meaning by itself, so you're saying more-or-less-explicitly that there is no meaning attached to the font-style change. (Much as I interpret the "i" tag: italics, but with no specific meaning - emphasis, book title, quotation - attached explicitly, as opposed to "em", which has an explicit meaning attached; though as we've found out, apparently some screen readers handle them identically.)

And [div] does... replaces the [span] above? Under what circumstances?

Yes, replace "span" with "div" in both opening and closing tag (but keep the rest the same).

Technically, "div" is a "block-level element" (like "p" or "h1" or "hr"), and "span" is an "inline element" (like "i" or "img" or "a").

Put very simply, block-level elements are blocks (roughly, paragraphs) of their own, whereas inline elements are contained inside blocks.

So, for example, if you want to have three italicised paragraphs, you would have to use

<p><i>This is the first paragraph</i></p> <p><i>This is the second paragraph</i></p> <p><i>This is the third paragraph</i></p>

. You have to use three separate "i" tags because they can only exist inside a block-level element like "p" and can't "escape" outside of their containing block to continue across multiple block-level elements. (In practice, browsers will let you get away with it and will italicise everything until the closing </i> tag, even if it's in a separate paragraph, but that's not valid HTML.)

"span" is like "i" in that respect; it's contained inside a block-level element such as a paragraph.

"div", on the other hand, starts its own block, so you can't use inside a paragraph. It can contain other block-level elements, though: so you can have, for example, <div style="font-style: italic"><h2>The Wizard of Oz</h2></div> -- or make three italicised paragraphs like this:

<div style="font-style: italic"><p>This is the first paragraph</p> <p>This is the second paragraph</p> <p>This is the third paragraph</p></div>

.

The italicised heading in the example you could also have written with span, since it was just one block: <h2><span style="font-style: italic">The Wizard of Oz</span></h2>. Note that the "span" goes inside the h2 element while the "div" goes around it.

Does that make some sense?

Finally, you can also add style="font-style: italic" to any other tag; I sometimes do so when quoting somebody in connection with the "blockquote" tag:

<blockquote style="font-style: italic"><p>This is the first paragraph</p> <p>This is the second paragraph</p> <p>This is the third paragraph</p></blockquote>

. That way, I don't have the meaningless tag "div" surrounding my three quoted paragraphs but the meaningful one "blockquote" (which means, roughly, "this is a block-level quotation (containing one or more paragraphs)"), but I attach some (meaningless) styling (italics, in this case) to it. (In most visual browsers, "blockquote" will result in a wider left margin for the quoted text.)

.
Thank you so much. You explain very clearly, and I really appreciate all the extra coding you had to do so that the actual coding was rendered. I'll save this and refer to it often. Maybe - eventually - <span> and <div> will be as easy for me as <i> and <b>.
.

Difference between italics and bold that I intend for vision only
why?

Sighted readers interpret italics a multitude of ways: as book titles, as emphasis, as a way to distinguish between quotes and replies (as both of us are doing here). You can't control how a sighted reader interprets the italics; why try to control how the blind reader does?

.
Because I don't expect book titles to be emphasized in speech; it seems -- rude, is the best explanation I can find -- to be emphasizing elements that are not part of a spoken pattern.

I expect the sighted reader to recognize the difference between the italics in, "Good grief! Can you believe what they said in the New York Times today?" To have those two read with the same amount of spoken emphasis isn't a realistic speaking pattern. And, as a matter of fact, I use [i] for the quotes that precede replies, because they don't actually need a spoken emphasis.

But you make a good point, especially if, as mentioned elsewhere, some screen-readers react to [i] and [em] the same way. I think I'll need to train myself to use single quotes when I want a visual distinction without spoken emphasis.

The problem is, as you say, I use italics for so many parts of a fanfic that don't need emphasis, such as the voice on the other end of the phone, dream passages or flashbacks, etc. Apparently, I need to re-evaluate my writing habits.
.

It's not so much your writing habits, but some fundamental differences between the web and the printed page. I know this is tl;dr but it's a topic I've been chewing on since 1988, so ahoy! brain dump ahead!

How I read your web page is a compromise between your intentions and my settings. You can't determine exactly what's going to be displayed, no matter whether I'm reading your wonderful fic on an Android phone or a braille terminal or a black-and-white character-only monitor in woefully-underfunded library at BackofBeyond.

For example, I set up Firefox with very large fonts. I find underlines ugly and light colors on dark backgrounds hard to read. I rely on NoSquint, a delightful add-on which permits me to set text zoom separate from page zoom, as well as text and background colors on a site-by-site basis. Among other things, it turns off all backgrounds, makes all text black, makes all links blue without underlines.

As a web author, it's safe to assume that links are always links. How links are shown is up to the end user and her browser (formally known as a "user agent"). Folks who assume that links are always underlined are reaching too far into the user's interface experience. For me, it's blue without underlines. For some screen reader users, links are set to a different voice; others prefer tones before or after or both; some like the word "link".

While many non-disabled users never touch the default settings, most disabled computer users get very familiar with configuration options. Because we're not typical, we're not average, and we've got to tweak a lot of options to get the optimal function.

As sighted readers, we're accustomed to intuiting structural meaning from the size, color, and choice of type fonts and the distribution of white space on the page. Many folks duplicate those effects on the web, because they're familiar. This "presentational" approach might create a heading by specifying a large font that's bold and centered. That's the sort of "HTML" which Microsoft Word and iWeb produce, and it's frustrating: it's inflexible, and requires the user to have a particular size screen. The web provides tools that permit us to declare the structure and functions of the text directly, indicated a heading with a tag like <h1>. When properly used, these tools make it possible for the identical structural information to be displayed on a smartphone or a huge monitor or via speech synthesis.

Secondly, I think you're confusing the speech output of screen reader software with the vocal stylings of a human narrator. When it comes to distinguishing possible meanings for italics and similar formats, I think it's safer (and more respectful) to assume all readers have the same toolkit. The community of screen reader users and designers works very hard to maintain parallel information. As long as you provide structural information, it's safe to assume that users of screen reader are familiar with variations in font presentation.

Have things changed a lot? The last time I really looked carefully, I saw JAWS literally reading Internet Explorer's output and calling that reading the web. It would make me very happy to hear that the manufacturers had gotten serious about it.

As long as you provide structural information, it's safe to assume that users of screen reader are familiar with variations in font presentation.

THIS. Basically, what you want to do is use structural, semantically meaningful markup. Trust the screenreaders (and the users of those screenreaders, who are responsible for the configuration) to do the right thing with that structural and semantically meaningful markup. They won't, all the time! Screen readers are imperfect tools, and they don't always react appropriately to the semantically meaningful markup. However, the tools are always improving, and the best thing you can do is trust the readers' tools to be doing what the readers want.

In other words, you don't want to be distinguishing between <cite> and <em> when you are formatting your text, avoiding using them sometimes because you don't want the emphasis to be spoken by a screenreader. Use the appropriate semantic markup, and trust that the presentation will take care of itself.

Edited (broken HTML element) 2010-04-06 03:11 (UTC)

.
Use the appropriate semantic markup, and trust that the presentation will take care of itself.

That's part of the problem: I'm not exactly sure what "the appropriate semantic markup" actually is.

I addressed several questions to

jesse_the_k; you may like to add some opinions or further input.
.

.
Secondly, I think you're confusing the speech output of screen reader software with the vocal stylings of a human narrator.

I'm sure I am. Since I know nothing except that they read webpages aloud (and I may even be off-base on that), I'm trying to learn from those who are familiar with screen-reader use.

As long as you provide structural information, it's safe to assume that users of screen reader are familiar with variations in font presentation.

This throws me for a loop. Are you saying that a screen-reader has the capability to distinguish between [1] a block of three paragraphs that are italicized to indicate a dream sequence (and therefore not to be spoken with extra emphasis), versus [2] two or three italicized words in dialog that are intended to be read/spoken with emphasis?

it's safer (and more respectful) to assume all readers have the same toolkit

See, I'm really trying to be respectful... which I thought would be to signal the screen-reader which italics were 'important' enough to be spoken with vocal emphasis. (Not using 'cite' - someone else explained why that is wrong - but using [span:italics] or [em].)

I'm sorry. I know I seem stuck on this, but I use a lot of italics in my fanfic, although probably only about 50% is inflected words in dialog. I'm just hung up with doing something wrong and accidentally making it less comfortable for screen-reader use, instead of more accessible.
.

The idea is that, just as you trust sighted users to parse the italics, you need to trust the screenreader users as well.

By semantic information, we mean use the tags with meaning instead of look whenever possible. <q>, <em>, <blockquote>, and <cite> might all be rendered differently by a screenreader; use them to give the screenreader a chance to cope with them. If you want a specific look and feel but, say, BLOCKQUOTE is appropriate and yet gives you a look and feel you don't like, style the tag with CSS to appear to sighted users as you like while still using the semantically right tag. But if that doesn't work, use <i> if nothing else applies. Just as sighted readers figure out how to parse italics (I know the ones used in your comment here are quoted strings, not emphasis or dream sequences), screen reader users can figure out the same thing.

More on those different tags, explaining the differences.

Edited (clarifying) 2010-04-09 02:05 (UTC)

.
style the tag with CSS

See, when I look at the link above (and others I've tried to understand), I just get more confused. Isn't CSS only when you're designing a website? I can't see how I would use a 'style sheet' when I'm posting fanfic to a current archive. I thought my only options would be to use various tags, and even those will be limited by what the archive allows.
.

On AO3, that's true; their interface strips all CSS before you post. Which is a little bit aggravating, actually. I've filed a bug about it, although I can see why they do it.

but on dreamwidth, you can use your own CSS. Even if you don't use your own CSS to write an entire style, you can embed CSS in something else you say. For example, I'm styling the following paragraph:

This is an overly styled paragraph!

Code looks like:

<div style="margin-left:2em;margin-right:2em;font-family:cursive;font-style:italic;color:blue;">This is an overly styled paragraph!</div>

You can do that around anything you post in dreamwidth,so if something is a blockquote but you don't like the blockquote style by default, you can use your own style. If you reuse the style frequently, you can write a little style sheet of your own to embed. I'm not sure if you can embed it in your journal style without a paid account,but you can certainly embed it manually at the top of each post.Getting into the technical details of how to do that is a little bit complicated unless you are sure it's something you want to try, but you absolutely can do it.

.
Thank you. I thought "CSS" by definition had to affect an entire page; I regarded <span style="font-style: italic"> as a 'tag' rather than 'CSS'. Maybe re-reading the comments will make a little more sense, now.

Getting into the technical details of how to do that is a little bit complicated unless you are sure it's something you want to try, but you absolutely can do it.

No; I'm happy just making very minor changes in my posts. Italics, bold, and blockquote are about all I need. (With the proviso that I'm trying to be sure I make those semantically accessible for screen-readers.)
.
.

Edited (I should finish my thoughts!) 2010-04-09 03:11 (UTC)

.
By the way... I've gotten so hung up on italics that I've forgotten all about horizontal rule. Is there a way to make a horizontal rule, or some form of section-break, accessible to screen readers?
.

I just checked, and by default, JAWS reads <hr /> as "dash dash dash dash". Presumably some JAWS users customize that, but my configuration is out-of-the-box, so by default the horizontal rule is accessible to screen readers.

And this, actually, is an extension of what people have been saying about semantic markup. Using the horizontal rule tag means that you can trust the screen reader to do what is necessary (configurable by the screen reader user). That means that if you've been using it, you are already being much more helpful to people who use screen readers than people who customize their own section break with something like "~~~~".

By the way, it's awesome that you are thinking about this so much!

.
Well, I didn't use horizontal rule in my personal LJ fic-journal; I considered it 'too plain'. But when I move everything to a DW fic-journal and to AO3, I'll change all my section-breaks to <hr>, since I've just recently learned that 'cute' section-breaks aren't cool for screen-readers.

Speaking of dash-dash-dash-dash: is there a preference between using a single dash (-) or coding an n-dash (–)? Do they 'read' equally, or is one a better option?

it's awesome that you are thinking about this so much!

Thank you. Mostly, it's a recipe of wanting to do things 'right' + enjoyment of solving puzzles (if they're not too complicated) + sheer stubbornness. But once I've figured out the current 'best' way, and can explain it to others, I'll put all the information in a neat post for all my friends to read and share. Hopefully, a lot of fanfic authors - well, those in my circle - will start coding for accessibility, even if they don't go back and recode their older stories.
.

This throws me for a loop. Are you saying that a screen-reader has the capability to distinguish between [1] a block of three paragraphs that are italicized to indicate a dream sequence (and therefore not to be spoken with extra emphasis), versus [2] two or three italicized words in dialog that are intended to be read/spoken with emphasis?

The screen-reader software doesn't distinguish these two uses of italic. However, your combination of cornea, iris, retina, and central visual cortex doesn't distinguish them either. In both cases, it's the human reader who's interpreting the italics. Some readers, whether sighted or blind, will understand that the first set of italics are a dream sequence while the second set is emphasized. Some readers, whether sighted or blind, won't.

1. Until W3C comes out with a final standard on aural stylesheets (which will probably happen real soon if I didn't miss it already) there will be things you can't do reliably. Once that standard is out, use it. The screenreaders will take a while to catch up, but your page will work (non-ideally) even for the ones that are behind the times.

2. Your main job when writing an accessible web page is to keep it clean. The more dirty tricks you play to get it to look right in browser A and B and to sound right in screenreader C, the more headaches you'll make for someone using browser E or screenreader F. Following the standards and the guidelines in the standards texts will take you far.

.
Your main job when writing an accessible web page is to keep it clean.

Well put; that's actually what I'm trying to do. I'm not developing a webpage for myself; I quail at the prospect. Mostly I'll be posting fic to AO3 and Dreamwidth, which are already pretty screen-reader compatible. (At least, that's what I'm told.)

But, in my posting, I'd like to be sure that the internal tags are as compatible as possible with screen-reader use. So, if <h3> is a better form for section headings than <b>, I can do that, and add better descriptions to my "alt" tags, and so on.

Once that standard is out, use it.

It's great that they're devising standards; I hadn't known. Is there a site that I can keep an eye on, for news when it happens?
.

The Web Accessibility Center at the Ohio State University has some excellent resources and examples. After you've explored there, you can spend many happy hours wandering the resources in their page o' links.

The single most useful site is WebAIM -- Web Accessibility In Mind. There you'll find robust discussions of accessibility standards in development, tutorials, standards, and answers to many questions: soup to nuts, experts to beginners.

For example, here's their survey of how 665 daily screen reader users experience the web.

.
Oh, my... I've bitten off more than I knew, haven't I? I guess I have a lot of studying to do. Thanks for the links.
.

HAI :)

Don't worry! It's both much more and much less complicated than it sounds. You don't need to learn how all 500,000 browsers interpret markup to post well coded fanfic. The thing to remember when writing accessible fic is to use semantically valuable tags. Here's a short intro to semantic xhtml.

The AO3 helps you choose better code with a handy guide on the Post New Work page. I'll reproduce it here:

For headings, use heading tags: h1, h2, h3, h4, h5, h6

<h1>Title<h1>
<h2>Subtitle<h2>
<h3>Chapter title<h3>
<h4>Scene title<h4>
<h5>Subtitle<h5>
<h6>Footnote title<h6>

For emphasis, use emphasis tags em, strong

<em>Rodney</em> McKay
I will <strong>never</strong> understand you!

To quote poetry, phrases or titles use quote tags: blockquote, q, cite

<blockquote>
To quote a block of text
</blockquote>
Use q to <q>To quote a phrase</q>
Try cite to cite <cite>a phrase or title</cite>

The AO3 is quite accessible already, but there is always more work to do of course. One of the things we are working on is more and better help. *g*

Edited (whoo! playing with editing comments!) 2010-04-03 11:22 (UTC)

.
Thank you for weighing in. I was told that AO3 is pretty accessible, but I'm trying to make sure I do my part of the job.

Are you saying that <cite will italicize on the page without spoken emphasis? Cool! That'll be much easier for me to remember (and code) than the <span code that another commenter suggested.

But what's the difference between <q> and <cite>? Is one more or less likely to be noticed by a screen-reader? If they do the same thing, <q> is even easier than <cite>... but I'm learning that my assumptions may leave me with egg all over my face.

Thanks for the link. Off to study.
.

Are you saying that <cite will italicize on the page without spoken emphasis? Cool! That'll be much easier for me to remember (and code) than the <span code that another commenter suggested.

I thought you were going to use semantic mark-up?

Please don't go back to 1990's HTML coding where people used whichever tag got them the appearance they wanted, regardless of what the tag was supposed to mean!

Use the tag that describes what you're doing.

But what's the difference between <q> and <cite>?

"q" is for quotations; "cite" is for citations or references to other sources (links are to the HTML specification).

"q" is easy enough to understand: you can use it to indicate that something is a quotation from somewhere else. (You can even indicate the source URL if you want: Joe Smith said, <q cite="http://www.example.com/page.html">I could do with a beer</q>.) It's an inline element, so it's probably better for shorter quotations.

Longer ones (a paragraph or more) are probably better expressed with "blockquote" (which also has the optional "cite" attribute if you want to provide a source URL). That one's a block-level element, so you can wrap one or more "p" elements inside it.

Note that some browsers (e.g. Opera), but not all, enclose "q" quotations in quotation marks -- so if you add quotation marks yourself, you'll have two pairs in some browsers, but if you leave them out, then browsers which don't add quotation marks won't show where the quotation starts and ends. What I usually do is italicise the quotation with <q style="font-style: italic">...quotation goes here...</q>.

The visual browsers I'm familiar with don't apply any particular font style to "q" quotations (or to "blockquote" ones, though they usually indent them).

I find "cite" hard to pin down the exact use of; the spec merely says that "the usual meaning" is "contains a citation or a reference to other sources", and the examples given are: As <CITE>Harry S. Truman said, <Q lang="en-us">The buck stops here.</Q> and More information can be found in <CITE>[ISO-0000]</CITE>.

So I suppose it's reasonable mark-up for book titles, but not (for example) for quoting someone or representing the voice on the other end of a telephone or thoughts, even if those are things you might want to mark up with italics and even if <cite> is often rendered as italics in visual browsers. Other than book titles, I'm not sure what the "cite" tag can properly be used for. (If you're going to use it improperly, then in my opinion you might as well go ahead and use the "i" tag, which at least doesn't even claim to indicate any particular meaning.)

.
I thought you were going to use semantic mark-up?

I'm obviously not getting the meaning you're trying to convey. I thought 'semantic' was a program that puts in bolds and italics for those who don't self-code in LJ.

But, yes, I want to be accessible-compliant. I'm just trying to figure out the easiest method of achieving that goal. If something is 'bad form', I won't do it, but I have to ask to learn.

Okay, I think I get what you're saying. But when I read fanfiction, I don't pay attention to whether something is a 'cite' or a 'quote'. It's irrelevant to the story, and I don't expect other readers to care, either. (Although I can see where it would be important on an informational web-page.) So should I stick to the <span-code for non-emphasized italics, and <em> when I want the emphasis?

Thanks for the extra links; I'll add them to my study line-up.
.

Semantic in this case means meaningful. *g* Semantics is the study of the meanings of words, phrases, texts. When web developers talk about "semantic markup", we mean using tags in a consistent way to give meaning to web pages. So h1 has a specific, particular meaning (of 'first heading') and we always use it in that way, just like words have meanings.

If we used words just because they sounded nice, or similar to the word we really meant, or completely without reason, it would be even harder to understand each other than it is already. The internet for a long time has been coded in this way, and it has caused a lot of problems. That is what pne is talking about, I would guess; for web developers it is a very frustrating situation.

Note that some browsers (e.g. Opera), but not all, enclose "q" quotations in quotation marks -- so if you add quotation marks yourself, you'll have two pairs in some browsers, but if you leave them out, then browsers which don't add quotation marks won't show where the quotation starts and ends. It doesn't just vary from browser to browser, but from style to style, even within Dwth. I started using <q> for quoting the OP or another comment, and found that there was no marker of it being a quote at all in, iirc, the site-style comment page. I've used <q> here, so I'll see what it does ...

In Comment Preview, it shows up in italics (no added quotation marks). I've a suspicion the italics disappeared when I posted such a comment before, but that might be something that's been fixed. Here goes!

And, it looks OK to me (so I guess that was a bug that's been fixed, or somebody's style that's not doing it right). I wonder what screen-readers make of it?

.
Well, I thought [q] or [cite] might be an easier way to produce non-emphasized italics. But the answer seems to be, "Sometimes, maybe, but you can never be sure." So, since they're not something I'll need in posting comments or fanfic, I'll just ignore them, and work on memorizing the [span italics] string.
.

Oh, I just saw in

changelog_digest
Make styling for the <q> tag consistent across all styles and site schemes
Consistently display the <q> tag as italics.
so on Dreamwidth, you could use that and it'll work, after the next code push.

.
Thanks for the heads-up. But I think it's safest to figure out one way and stick to it, which is to use [em] and maybe [span:italic] as necessary. (I'm still researching that one.)
.

So, the answer is to let go of what things look like, and concentrate on what things mean. q and cite are not about emphasis, they are ways to say "this sequence of words is a reference from or to another work". That could be a title of a book, or a line from a song, or a quote from a speech, or a number of other quotes or cites.

In some cases it is a judgment call, and don't get too tangled up in it. There's a reference page called Paragraphs, Lines, and Phrases, that you may find useful to check your decisions against.

In general it seems to me that you are focusing on what things look like - italicisation - but this way of communicating by manipulating typography, is purely sighted. It's not relevant to (most) users of screenreaders, just as it would not be meaningful in a radio play or a phone conversation. But these ways of conveying narratives are semantically rich, aye? So instead of thinking 'how can I make it look this way?', think 'what am I saying when I make it look like this?'.

If you can work out what you really mean, it is much easier to decide how to say it. This is as true with coding as anything else.

.
In general it seems to me that you are focusing on what things look like - italicisation - but this way of communicating by manipulating typography, is purely sighted. It's not relevant to (most) users of screenreaders,

True. When I post comments, most italics means emphasis, so [em] is appropriate. But when I post fanfic, about 50% of the italics I use means spoken emphasis, but the other 50% is a convention that is useful for sighted but would be very uncomfortable to listen to if it was all emphasized. This is why I'm trying to learn a way to make italics that the screen-reader will not emphasize. It seems that [i] is given emphasis in some screen-readers, so that can't be my difference. (Although I do use it for marking the part of comment I'm responding to - as above - just in case it works.) I'll memorize the [span italics] string and use that in my fanfic and, when I'm comfortable with it, in my comment-markers.

I'm trying to be aware of both groups of readers; I want the story to sound natural (spoken emphasis only on appropriate words in dialog), while at the same time giving unemphasized italics cues (book titles, dream sequences or flashbacks) to visual readers. This discussion branched out into other areas, but I've learned a lot. I'll never develop a website, but at least I'll use what's available a little more accessibly.
.

.
Oops. Within the linked article is: "Here are two PDFs: [html] [css] Print them out. They contain, on two A4 pages, everything you will ever need to know about HTML and CSS." But both links give me "Server not found." Do you have alternate links?
.

HTML: http://www.addedbytes.com/cheat-sheets/html-cheat-sheet/, CSS: http://www.addedbytes.com/cheat-sheets/css-cheat-sheet/

That seems to be the current home of those files.

.
Thank you.
.

Oh! Very useful, thanks! I'll change those links. :D

Accessibility question

no subject

no subject

no subject

no subject

no subject

no subject

width and height in images

Re: width and height in images

Re: width and height in images

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

<h1>Title<h1>

<h2>Subtitle<h2>

<h3>Chapter title<h3>

<h4>Scene title<h4>

<h5>Subtitle<h5>

<h6>Footnote title<h6>

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject