I have a question about how tags should (or should not) be nested in the Tags pane. As you can see below, all of the tags in this document are nested underneath the <Document> tag:
Similarly, all of the sub-parts of a list are nested beneath the <L> tag. The <LI> tags are nested under the <L> tag; the <Lbl> and <LBody> tags are nested underneath the <LI> tag:
So my question is, why aren't the tags for the contents of a section nested under the heading for that section? And why aren't the heading tags nested under the heading tags immediately above them in the document hierarchy? Isn't the Tags pane supposed to show the structure of the document?
I *think* the left-hand image is the correct way to arrange the tags, not the right, but why?
SueHayTM wrote
So my question is, why aren't the tags for the contents of a section nested under the heading for that section? And why aren't the heading tags nested under the heading tags immediately above them in the document hierarchy?I *think* the left-hand image is the correct way to arrange the tags, not the right, but why?
Because the tags used for accessibility are NOT the same as XML tags.
They are similar to, but not the same, as HTML tags.
They really are just labels wrapped up in pointy-brackets.
Very few of our accessibility tags require a structure like L / LI / Lbl / Lbody or the group of table tags.
Assistive technology users usually prefer a clean, straightforward tree like your sample on the left.
When we talk about the loosey-goosey term "structure" in accessible documents, we really mean a very lite version of structure that depends mainly on the tag (or labels) themselves and their reading order in the Tags panel.
Your example is leaning toward XML, which can require all sorts of hierarchy of tag elements. But XML is extensible, meaning that whoever uses it makes up the rules via its scheme or DTD. There are exceptionally few universal "standards" of XML architecture (and they can be a royal PITA to work with). Sure hope we don't go down that path with accessibility!
In your right-hand example, I believe it's incorrect to have <P> and anything else nested inside a <Hx> tag (I do not have my ISO standards handy to check, so this is from memory). But think this through a bit: if you were using a screen reader and invoked the keyboard shortcut to voice out all the headings, you'd hear not only the <H2> but also everything in it. OMG. NIGHTMARE>
Also, only the designated container tags <Part>, <Art>, <Sect> and <Div> are allowed to contain other elements like <P>, <Hx> etc. See: https://helpx.adobe.com/acrobat/using/editing-document-structure-content-tags.html#standard_pdf_tags and note what's in the section titled Container Elements.
So the correct structure in your right-hand version would have to be:
<Sect>
<H2>
<P> (not that it is NOT inside the H2 tag, but is inside the Sect container.
If it's a longer document, start bringing in <Part> and <Article> tags to denote the major components of your document. Reserve <Sect> for small accessory "stories" to a major story like sidebars, a group that includes a photo and its caption, or a group that includes a figure title, prefatory information, the <Figure> graph itself, and its footnotes. And the <Div> tag is not recommended at this time.
FYI, I noticed you typed titles on the <H2> tags, <H2> Purpose of Travel. Not necessary and I honestly can't think of any benefit that would have to someone who uses AT. Save your time!
However, it will become helpful in the future to put titles like that on <Part>, <Art>, and <Sect> container tags that can identify major sections of a document. But not on heading tags.
Hope this helps.
--Bevi Chagnon
Accessibility Consultant | www.PubCom.com
5
Replies
SueHayTM wrote
So my question is, why aren't the tags for the contents of a section nested under the heading for that section? And why aren't the heading tags nested under the heading tags immediately above them in the document hierarchy?I *think* the left-hand image is the correct way to arrange the tags, not the right, but why?
Because the tags used for accessibility are NOT the same as XML tags.
They are similar to, but not the same, as HTML tags.
They really are just labels wrapped up in pointy-brackets.
Very few of our accessibility tags require a structure like L / LI / Lbl / Lbody or the group of table tags.
Assistive technology users usually prefer a clean, straightforward tree like your sample on the left.
When we talk about the loosey-goosey term "structure" in accessible documents, we really mean a very lite version of structure that depends mainly on the tag (or labels) themselves and their reading order in the Tags panel.
Your example is leaning toward XML, which can require all sorts of hierarchy of tag elements. But XML is extensible, meaning that whoever uses it makes up the rules via its scheme or DTD. There are exceptionally few universal "standards" of XML architecture (and they can be a royal PITA to work with). Sure hope we don't go down that path with accessibility!
In your right-hand example, I believe it's incorrect to have <P> and anything else nested inside a <Hx> tag (I do not have my ISO standards handy to check, so this is from memory). But think this through a bit: if you were using a screen reader and invoked the keyboard shortcut to voice out all the headings, you'd hear not only the <H2> but also everything in it. OMG. NIGHTMARE>
Also, only the designated container tags <Part>, <Art>, <Sect> and <Div> are allowed to contain other elements like <P>, <Hx> etc. See: https://helpx.adobe.com/acrobat/using/editing-document-structure-content-tags.html#standard_pdf_tags and note what's in the section titled Container Elements.
So the correct structure in your right-hand version would have to be:
<Sect>
<H2>
<P> (not that it is NOT inside the H2 tag, but is inside the Sect container.
If it's a longer document, start bringing in <Part> and <Article> tags to denote the major components of your document. Reserve <Sect> for small accessory "stories" to a major story like sidebars, a group that includes a photo and its caption, or a group that includes a figure title, prefatory information, the <Figure> graph itself, and its footnotes. And the <Div> tag is not recommended at this time.
FYI, I noticed you typed titles on the <H2> tags, <H2> Purpose of Travel. Not necessary and I honestly can't think of any benefit that would have to someone who uses AT. Save your time!
However, it will become helpful in the future to put titles like that on <Part>, <Art>, and <Sect> container tags that can identify major sections of a document. But not on heading tags.
Hope this helps.
--Bevi Chagnon
Accessibility Consultant | www.PubCom.com
Sue -
I can completely understand why you might think that things might need to be nested as a child of the Hx tag, but hopefully this might help to provide extra clarity from a new perspective. I like to think of the tree like boxes. Everything goes inside the Document box. Then, if for organizational sanity, I want to have articles, sections or parts, I can put those inside the Document box. Let's say I decided I have a document and I decide to use sections to divide my content. Then inside the section I will have things like headings, paragraphs, figures lists forms and links all ordered neatly in the order I want them to be read and each containing the text I want them to read. I would never open the box for headings and put my form in it because it already if filled with the heading text. Nor would I put a heading INSIDE my paragraph. It would be "in front" of, or "on top" of the paragraph. When you can think of it that way, it makes a lot more logical sense.
In addition to reading in a linear fashion, it is common for blind people to jump to specific content to navigate a document. With JAWS you can pull up the "list of lists" (ins+F3) and then pull up all sorts of things like the headings in a document. As a matter of fact, blind people use this so much that JAWS has build in default shortcuts for Headings lists (ins+F6), Form Lists (ins+F5), Link Lists (ins+F7). Tags are the structure in which non-sighted people navigate multi-part documents on a regular basis and that is why it is so key that we use the tag structure in a way that gives them the most flexibility in digesting what is on the page. Giving them multiple ways to access the content answers the "Robust" in the P.O.U.R. principals of accessibility.
Hopefully that helps in addition to Bevi's (always insightful) comments.
-Dax
AdChoices