Accessibility question

[starwatcher]

I will soon be moving my fanfic to Archive of Our Own, and to a Dreamwidth fic-site. When moving the fics, I'd like to ensure that my code is accessible for screen-readers. I know some things, but have questions about others. I asked the questions in a post at my Studio, but have had no responses; apparently no one in my reading circle uses a screen-reader.

If you do, I'd appreciate it if you could drop by and educate me. Or perhaps point me toward a site that has the answers. Feel free to pass the link on to anyone who might know the answers. After I've learned what I need to know, I'll make a new post to share with my friends, and anyone else who needs or wants the information.

Thank you.

Comments

[starwatcher]

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

[jesse_the_k]

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.

[treeowl]

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.

[jadelennox]

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.

[starwatcher]

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

[starwatcher]

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

[jadelennox]

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.

[starwatcher]

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

[jadelennox]

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.

[starwatcher]

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

[starwatcher]

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

[jadelennox]

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!

[starwatcher]

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

[jesse_the_k]

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.