What should be the heading level in a D2L rich text field?
When a course author wishes to structure a portion of a D2L page with headings, what is the correct level to use as the first heading? I assume that in the iframe of a Daylight content page, the html page used should have an h1 as the first text element.
But what about:
- A home page widget?
- An announcement in the Announcements widget on a course or institutional home page?
- A tool item description (Discussion and Assignments, e.g.)?
- A quiz question?
I am asking in relation to accessibility; we can certainly style any level of heading to look good in context. But what will make the heading be read and navigated correctly by a screen reader in the above contexts?
Answers
-
@Heather Baker, This seems right up your alley. Thoughts on the best methodology?
-
Thanks Heather!
-
Here is fine! It's a good question Renee, however, doesn't have a straightforward answer.
As you've hinted at in your question, the content author should be aware of the heading structure of the page where the content will be used. For Announcements, content in the HTML Editor would actually start with an H4 if viewed from the homepage - as the announcement title is an H3. The same is true for quizzes where the quiz question number is an H3. In Content, it is appropriate to start with an H2 - but this isn't a great practice if you plan to use the content outside our system as then it will be missing an H1.
There’s extra complexity here too since for announcements specifically, they can be viewed from several places (homepage, the announcements tool itself, places like mobile and other tools) — each potentially with different heading contexts. Knowing the “right” heading level to use becomes impossible.
Our dev teams have talked about ideas for handling this better however not come to a plan yet.
-
Testing reply by email. Should I ask this question on the regular community site so it can be answered there? It actually is something I’m thinking about because we are redesigning widgets for Daylight, and building draft announcements as part of the communication plan for our future daylight release. By the end of May, our team will commit to turning on Prod site Daylight for fall term, or waiting until winter quarter. (Our only break between terms is fall-to-winter, which is almost a month!) srj
-
And this is why the only context where I use formatted text masquerading as headings is d2l text fields (other than Content). I figure I won't provide screenreader users with any navigation help, but at least I won't throw the page outline off!
The one thing that I now feel confident about is home page widgets. I can see in the source code for home pages that the heading that used to be the nice, configurable widget title bar is H2. So custom widget content would have headings start with H3. I checked this on both course and institutional home pages. Yay!
As you point out, the announcement content multiple context contexts, so maybe I should just go with my wimpy inline css for heading-like styles, like before.
As to content, your ice cream pages start with H1 the same as every page in every course we have, so I am praying that your accessibility testing has got us covered!
-
Have there been any updates to this issue? I'm redoing our CSS templates right now, and while it seems like starting with H1 in Content will be fine, we have a lot of inline styling in Announcements that would possibly be wrong. Is there a specific answer to the heading style we should start with in Announcements, is it still page-specific, or has this been solved?
-
Now that I have had time to reflect and read source code, @Heather Baker, I am comfortable not adjusting my original approach to content pages. Our designers and builders will continue to receive a standard of new html pages that are both accessible and responsive as independent pages, and legacy xhtml page updates that are aware of this standard.
I absolutely must continue to believe that the full html page that is rendered in an iframe becomes a new browsing context.
Thinking about it that way, whether or not there can/should be multiple h1 elements on a page (which is still debatable by experts and standards-writers for html5) becomes almost trivial with regard to the h1 in the header of the iframe's included content page.
The html document we upload to manage files begins with declarations that occur only once, with a head, with a body. Browsers will "know" how to deal with this in rendering the page. Hopefully html's "main", which is also once-only thing, has been folded into the inclusion process.
Again, I'm assuming that the Brightspace front-end engineer(s) who tested your ice cream template for accessibility also would be comfortable with similar assumptions. I myself have limited vision, but I still access pages visually most of the time. I am not an expert user of screen reader technical, and at my neophyte level am not able to successfully navigate D2L. I therefore depend on Brighspace's accessibility for built-in D2L functionality. To me, this functionality includes the ability to upload a complete (and accessible) html page and its supporting files to Manage Files, and have that content accessible in the Content tool.
That's how it works, right?
