heading rank in aside/article/nav

[peppobon]

As we are talking about going forward with edupub, I would like to raise (maybe again, sorry) the structural issues related to what is stated [here] (http://www.idpf.org/epub/profiles/edu/spec/#h.9obeul6ergfp) in the EPUB for Education draft regarding heading rank inside aside/article/nav element.

My point is that asides are by definition out of the main flow of the content (particularly in higher education textbooks) and therefore imposing an heading rank based on the aside's outer context is probably wrong and for sure very annoying when you need to reorganize/reshuffle/move around pieces of content.

In the last months we converted from DTP files a lot of structurally very complex content and we have found that starting always the aside inner sectioning at h5 is a far better option.

If I remember well, all this was related to a9y issues, which I think could be addressed by ARIA roles.

regards,

__peppo

[dualpixel]

Hi, @peppobon Noe a days, besides, iBooks is there other reading system that recognize well Structural Semantics?

Regards

[peppobon]

@dualpixel Good point.

RD support of structural semantic is very weak (even in browsers), but the whole point of edupub is, in my opinion, having interoperable html files that can be used as sources to generate efficiently different renditions of a "book".

I see edupub more as a src/archive format than an output format, but here I am probably alone!

On Thu, May 25, 2017 at 2:12 PM, Felipe Santos notifications@github.com wrote:

Hi, @peppobon https://github.com/peppobon Noe a days, besides, iBooks is there other reading system that recognize well Structural Semantics?

Regards

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/publ-cg/issues/5#issuecomment-303995767, or mute the thread https://github.com/notifications/unsubscribe-auth/ABkS-CUSr4Myf27gOBcC7OtboVYEbNNGks5r9XAlgaJpZM4NlUol .

[BillKasdorf]

Re:

I see edupub more as a src/archive format than an output format, but here I am probably alone!

You are not alone. In my experience this has actually turned out to be the primary use of EDUPUB/EPUB for Education.

Bill Kasdorf

VP and Principal Consultant | Apex CoVantage

[mattgarrish]

This goes back to the lack of support for the outline algorithm. If it were actually true that an aside were outside the document outline, then, yes, we wouldn't have to worry about heading sequence. But the reality is that the outline isn't supported and that's why the HTML spec notes the need to build one using h1-h6 tags (and ARIA role="heading" + aria-level="#").

An aside is a subsection of the section is belongs to, regardless of its internal structure, which is why the recommendation is in place that the first heading start one level lower than the containing section.

I'm not going to dispute that it requires additional work for content reuse, but user needs also trump developer needs. If we pick an arbitrary heading level to start at it may work sometimes, but more often it's going to result in gaps in the outline or leave asides appearing to be higher-level sections.

But if we reference the accessibility specification, I don't know if we have to keep these rules. They flow out of WCAG, too, so content will fail without our duplication of the rationale.

[RachelComerford]

Avneesh - can the accessibility subgroup discuss whether this is redundant with WCAG and if it needs to be outlined in epub for education?

[avneeshsingh]

Right now WCAG does not cover the case in which structure is spread over multiple files. Accessibility TF will work with WCAG on such issues. We will also include cases like aside. Regarding EPUB for education, as per my understanding, it already have more strict mark-up for headings to help in hierarchy across multiple files. Chapters are inside section tags, so it differentiates from aside. But there is a mis match here, we do not promote use of section tag in EPUB accessibility conformance and discovery specification. So, this is another item for aligning EPUB for education.

[mattgarrish]

The sectioning and heading requirements are in separate sections. The use of sections isn't covered by WCAG, but heading order is so we may not need it.

Our techniques document also has a couple of sections on headings in publications, so if we reference the accessibility specification I'm not sure the prose about headings in the edupub specification is useful anymore.

I'm also not sure I understand yet if the section requirement is being dropped. It sounds like it will be, in which case nothing else is needed. If it's retained, there might be a case for requiring the AAA SC that deals with headings as part of referencing the accessibility specification.

At any rate, if aside can start with any ranked heading, it sort of undercuts the requirement that document heading structure represent the outline. There's nothing that actually removes the structure in the aside (or article or whatever) from the outline that assistive technologies generate.

[GeorgeKerscher]

If it is covered in WCAG, then we could add a manual check to Ace for all cases where there is a heading inside the aside; then we are done with it.

Thoughts?

Best George

From: Matt Garrish [mailto:notifications@github.com] Sent: Monday, July 10, 2017 12:31 PM To: w3c/publ-cg publ-cg@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [w3c/publ-cg] heading rank in aside/article/nav (#5)

The sectioning and heading requirements are in separate sections. The use of sections isn't covered by WCAG, but heading order is so we may not need it. Our techniques document also has a couple of sections on headings in publications, so if we reference the accessibility specification I'm not sure the prose about headings in the edupub specification is useful anymore. I'm also not sure I understand yet if the section requirement is being dropped. It sounds like it will be, in which case nothing else is needed. If it's retained, there might be a case for requiring the AAA SC that deals with headings as part of referencing the accessibility specification. At any rate, if aside can start with any ranked heading, it sort of undercuts the requirement that document heading structure represent the outline. There's nothing that actually removes the structure in the aside (or article or whatever) from the outline that assistive technologies generate. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/publ-cg/issues/5#issuecomment-314194516 , or mute the thread https://github.com/notifications/unsubscribe-auth/AG3HSKpKHG4XZIzQqEQp_6VjSt8cowl-ks5sMm3zgaJpZM4NlUol . https://github.com/notifications/beacon/AG3HSEXIyIFR6O4GVLH3qpaI2vP_Ijacks5sMm3zgaJpZM4NlUol.gif

[mattgarrish]

It should be automatable. Whether the heading(s) inside an aside flow sequentially from the parent section can be verified by machine. Techniques G141 and H42 cover this for SC 1.3.1, which is Level A. Using the correct heading rank establishes that it is a subsection of content.

And as far as I'm aware, AT will announce an aside as complementary content, so it shouldn't be confused for the main flow. The only issue is escaping/skipping. I don't know if that's supported for asides or articles or navs.

[peppobon]

Sorry if I insist, but I think that asides (at least in the book publishing context, particularly in education) must be considered as autonomous content out of the main flow of the text and therefore they do not belong to the sections hierarchy. If they were in the main flow, they would be marked up as div (probably with a class or another semantic indicator), not as asides.

From a semantic point of view divs do partecipate indeed to the sections hierarchy, but asides not.

[artbyrt]

I'm not super familiar with the hierarchical subtleties, but the really important function of asides in RS render is with footnotes which are definitely linked to section and need to be better supported (round-tripping).

Ruth Tait http://artbyrt.com

On Jul 11, 2017, at 4:41 AM, peppobon notifications@github.com wrote:

Sorry if I insist, but I think that asides (at least in the book publishing context, particularly in education) must be considered as autonomous content out of the main flow of the text and therefore they do not belong to the sections hierarchy. If they were in the main flow, they would be marked up as div (probably with a class or another semantic indicator), not as asides.

From a semantic point of view divs do partecipate indeed to the sections hierarchy, but asides not.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[mattgarrish]

Asides are announced as complementary content, including the headings when you navigate them by shortcut.

But the headings are mapped to their stated level, so it still makes navigation confusing if their headings don't follow logically as subheadings of their containing section.

For example, if you go back to read the sidebars in a section with a level 3 heading, if the asides don't start with an h4 heading then the user has to navigate one heading at a time to figure out where the sidebars are, or guess which level they might be at (including higher than their containing subsection).

If they do start with h4, the user can jump from h4 to h4 until they hear it's complementary content and then listen to determine if it's the one they were looking for.

[JayPanoz]

@peppobon

As @mattgarrish said, the root of this issue is the outline algorithm. If you want this eventually solved, you should probably report this in the existing WHATWG issue.

Reading System developers can’t fix browsers (rendering engines). In most cases, they can only put a band-aid on a wooden leg – especially when the fix requires the RS getting around how browsers work. Only browser vendors (and close contributors) can fix browsers in a way which will 1) be sustainable and 2) benefit the whole ecosystem.

For instance, as a RS contributor, I have to report EPUB-related issues to the CSSWG/spec editors in most cases, or else they wouldn’t even know those issues exist, and web browsers either. So it’s important we don’t stick to the epub-cg or epub-revision if issues apply to the web platform as well.