<i>, <em> or <span> for italics ?

[JSWolf]

I have seen <hr/> used for a section break marker to have a thin line. It works pretty well.

[Turtle91]

I think what the accessibility group was getting at, was that software can be programmed to recognize an <hr/> and treat it differently than the <p> or <div>. Visually it doesn't make a difference, but the standards that support accessibility should be followed.

Using their 2nd example, I was able to include images, or fleurons, within the <hr/>. It actually became easier/shorter to code as well.

I previously used this when inserting a scene break:

<div class="ChDiv"><img alt="" src="../Images/fleur.gif"/></div>

Now I can use:

<hr class="ChDiv"/>

and the CSS for <hr> is fairly straight forward:

hr.ChDiv {
  border:none; 
  margin:1.25em auto; height:.5em;
  background: transparent url("../Images/fleur.gif") no-repeat center;
  background-size: auto 100%;
  overflow: hidden;
  page-break-inside: avoid;
  break-inside: avoid;
}

[Hitch]

Originally Posted by Turtle91

I think what the accessibility group was getting at, was that software can be programmed to recognize an <hr/> and treat it differently than the <p> or <div>. Visually it doesn't make a difference, but the standards that support accessibility should be followed.

Using their 2nd example, I was able to include images, or fleurons, within the <hr/>. It actually became easier/shorter to code as well.

I previously used this when inserting a scene break:

<div class="ChDiv"><img alt="" src="../Images/fleur.gif"/></div>

Now I can use:

<hr class="ChDiv"/>

and the CSS for <hr> is fairly straight forward:

hr.ChDiv {
  border:none; 
  margin:1.25em auto; height:.5em;
  background: transparent url("../Images/fleur.gif") no-repeat center;
  background-size: auto 100%;
  overflow: hidden;
  page-break-inside: avoid;
  break-inside: avoid;
}

Dion, dear, since I'm a lazy old thing, can you slap the sample ePUB/MOBI in here? That contains that test code?

Hitch

[Turtle91]

Originally Posted by Hitch

Scroll down on that page; they disagree. (About CSS/margins, etc. FWIW, I agree with you.) And why on earth does one empty paragraph somehow "signal" that something's going to change? Have they LOOKED at the average, typical, DIY from-Word self-published book?

Why shouldn't I use CSS to increase padding or margins to get the same effect?
Although you may get the same visual effect, the user is given no information that a change in context has occurred. CSS class names carry no semantic meaning.

Print-first workflow tools often use this CSS technique to indicate context changes when exporting, but it is inherently inaccessible.

I was a little confused over that too...but I think they are referring to using margins this way:

.SecBrk {margin-top:2em}

<p>Para before the break/</p>
<p class="SecBrk">Para at the break.</p>
<p>Para after the break.</p>

I don't think they were trying to justify the empty paragraphs. (at least that's the way I choose to interpret it to preserve my sense of a well ordered world! )

[Turtle91]

Originally Posted by Hitch

Dion, dear, since I'm a lazy very busy old thing revered elder??, can you slap the sample ePUB/MOBI in here? That contains that test code?

Hitch

Sure thing!

The first fleuron is using my <div> method, the second is using the <hr>.

[JSWolf]

Originally Posted by Turtle91

I was a little confused over that too...but I think they are referring to using margins this way:

.SecBrk {margin-top:2em}

<p>Para before the break/</p>
<p class="SecBrk">Para at the break.</p>
<p>Para after the break.</p>

I don't think they were trying to justify the empty paragraphs. (at least that's the way I choose to interpret it to preserve my sense of a well ordered world! )

Your section break should be padding-top: and not margin-top:. The reason being that padding works when the section break is at the bottom/top of the screen where as margin does not work so well at the bottom/top of the screen.

[Hitch]

Originally Posted by Turtle91

Sure thing!

The first fleuron is using my <div> method, the second is using the <hr>.

Thanks, bud.

I'll take a look. We try--we do--to address usability and all that, but sometimes, they kinda make me want to scream. I mean...we have a book in with 654 images. (sigh). And of course, the author didn't put in title or meta info!

Hitch

[Turtle91]

Originally Posted by JSWolf

Your section break should be padding-top: and not margin-top:. The reason being that padding works when the section break is at the bottom/top of the screen where as margin does not work so well at the bottom/top of the screen.

You can certainly use padding if you wish. The use of margin here was simply an example of what the article was referring to...they were talking about margins, so I used margins.

[DaleDe]

I noticed that the image examples don't fill in the alt entry. This, if it were filled in, would identify the break automatically.

Dale

[JSWolf]

Originally Posted by Turtle91

You can certainly use padding if you wish. The use of margin here was simply an example of what the article was referring to...they were talking about margins, so I used margins.

I used to use margins for section breaks. I forget where I picked up padding instead of margins for section breaks. But padding does work must better.

[Turtle91]

Originally Posted by DaleDe

I noticed that the image examples don't fill in the alt entry. This, if it were filled in, would identify the break automatically.

Dale

I don't think it identifies a scene-break. It is simply an alternate display if the image is not available, correct?

If you used: alt="Scene Break" it would simply display "Scene Break" in place of the image. The added benefit is an accessibility device would read the words "Scene Break" aloud.

I don't know exactly how accessibility devices treat a scene break differently, perhaps someone here can explain better??

[DaleDe]

Originally Posted by Turtle91

I don't think it identifies a scene-break. It is simply an alternate display if the image is not available, correct?

If you used: alt="Scene Break" it would simply display "Scene Break" in place of the image. The added benefit is an accessibility device would read the words "Scene Break" aloud.

I don't know exactly how accessibility devices treat a scene break differently, perhaps someone here can explain better??

Why wouldn't the image be available? It is for reading out loud and can be anything you want. Yes "scene break" might be the thing you would want it to say.

Dale

[Tex2002ans]

Originally Posted by JSWolf

I used to use margins for section breaks. I forget where I picked up padding instead of margins for section breaks. But padding does work must better.

The margin/padding difference was if it occurs at the very top of a screen when you move to next page.

Margins got eaten, padding stays.

Originally Posted by DaleDe

I noticed that the image examples don't fill in the alt entry. This, if it were filled in, would identify the break automatically.

alt="" (or alt="*") is the correct choice.

See Example 8, WebAIM "Alternative Text":

Decorative images do not present important content, are used for layout or non-informative purposes, and do not appear within a link. In almost all cases, spacer and decorative images should have null alt text (alt="").

Note
When an image is used only for decorative purposes, it is often best to remove the image from the page content and add it as a background image using CSS. This will remove the need for alternative text at all and will remove the image from the semantic and structural flow of the page.

Originally Posted by DaleDe

Why wouldn't the image be available? It is for reading out loud and can be anything you want. Yes "scene break" might be the thing you would want it to say.

I think that's why HTML5 pushed for using <hr> in this case instead.

If that HTML5Doctor article was correct, it would be the same as if you did </section><section>.

<section> is a new HTML5 tag, and allows users to navigate more easily (similar to headings):

https://developer.mozilla.org/en-US/...lement/section

So let's say in a Fiction book, each scene could be in its own <section>:

<section>
	<h2>Chapter 1</h2>
	<p>The green cow woke up, [...]</p>
</section>
<section>
	<p class="scenebreak">* * *</p> <--- (or <img> here)
	<p>Stumbling through the meadow, [...]</p>
</section>

Or, (I think), equivalent would be this:

<section>
	<h2>Chapter 1</h2>
	<p>The green cow woke up, [...]</p>
	
	<hr class="scenebreak" />
	
	<p>Stumbling through the meadow, [...]</p>
</section>

and then you can load a decorative image via CSS, like Turtle91 pointed out.

This would still allow a blind reader to hop to the next section, just like they could jump to the next <h2> or chapter.

* * *

Nowadays, on more modern browsers, there's the Accessibility Tree + ARIA:

• Mozilla Hacks, "How accessibility trees inform assistive tech"
• Google Developers, "The Accessibility Tree"
• Mozilla Web Docs, "ARIA"

ARIA (Accessible Rich Internet Applications) lets you assign labels/roles, and nudge the browser in certain ways. Like you can tell the browser "these are navigation links":

Spoiler:

<div role="navigation">
<ul>
	<li><a href="HomePage.xhtml">Home</a></li>
	<li><a href="Forums.xhtml">Forums</a></li>
	<li><a href="About.xhtml">About</a></li>
</ul>
</div>

A screen reader can then treat those differently than your typical links within an article.

The Accessibility Tree lets you see the semantics and innards behind code... and the HTML5 tags, by default, already map to ARIA stuff. This is one of the reasons why semantics is much more important.

Side Note: Of course, you can also go in the complete opposite direction and begin bungling it up "when trying to be helpful" and over-assigning ARIA roles/labels. Again, this is why it's a little better to err on the side of KISS.

One of the blogs I love to read is "Marco's Accessibility Blog". He's a blind web developer and has done a ton of coding and enhancements for Mozilla/Google/WordPress/NVDA. And since he's blind... he explains all the typical pitfalls/pain-points.

[Land_Outcast]

Originally Posted by Turtle91

Yes, I also use this technique when I don't want, or can't have, a visual representation on the page but still need the structural definition of a header...and the functionality of an auto-generated TOC.

eg.

<h2 title="Copyright" style="display:none" />

For what it is worth, I just discovered “display:none” in a heading (h#) generates problems in conversion to kindle format:

["E24010: Hyperlink not resolved in toc (One possible reason can be that the link points to a tag with style display:none):/tmp/mobi-1Mmqfm/OEBPS/Text/EBOOK_PAEZ_VILARO-Entre_mi_hijo_y_yo_la_luna-1.xhtml#_idParaDest-1", "E24001: The table of content could not be built.", "W14001: Hyperlink not resolved: /tmp/mobi-1Mmqfm/OEBPS/Text/EBOOK_PAEZ_VILARO-Entre_mi_hijo_y_yo_la_luna-1.xhtml#_idTextAnchor000", "W14002: Some hyperlinks could not be resolved."]

[Hitch]

Originally Posted by Land_Outcast

For what it is worth, I just discovered “display:none” in a h1 generates problems in conversion to kindle format:

YES. I've been meaning to mention that, but it's been bonkers at my office so my answers/posts over here are quick/scant. For mobi, via KP, it's ixnay on the hidden-ay.

Hitch