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

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