Re: DPUB module comments

Is there a reason that a document using DPUB roles can not use standard 
ARIA roles when they apply?

In the case of "landmarks" role, the description perfectly matches the 
standard "navigation" role. So, why not just use role="navigation"?

It also seems that role="heading" would perfectly map to the proposed 
role="title".

The links to parent roles are not working for me in the rawgit rendering.

Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement 
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com



From:   Matt Garrish <matt.garrish@bell.net>
To:     "James Craig" <jcraig@apple.com>, <tsiegman@wiley.com>, 
<mgylling@daisy.org>, "Michael Cooper" <cooper@w3.org>, 
Cc:     "HTMLWG WG" <public-html@w3.org>, "W3C WAI Protocols & Formats" 
<public-pfwg@w3.org>
Date:   03/10/2015 11:52 AM
Subject:        Re: DPUB module comments



Some thoughts below.

> 2. Roles should sub-level hyphenation. E.g. page-list should be
> dpub-pagelist.

These terms came from the EPUB vocabulary, but creating mappings to a 
different naming convention doesn't seem problematic.

> 4. Several of the roles are probably too specific. "learning-outcome" 
and
> "learning-objective" for example.

I personally agree. I think these two are too domain-specific, and the 
goal 
was not to include all edupub terms (assessment terms were removed for 
further review - potentially to include in a domain-specific vocab). We 
did 
add a note about these two being still under consideration for inclusion, 
but that also includes removal.

> 5. Some should be expanded for clarity: "glossdef" and "qna" for 
example.

Again, sounds reasonable if that's preferred practice here.

> 6. "landmarks" is going to confuse a lot of authors.

In epub, this navigation aid allows the reading system to provide quick 
access to major landmarks that are typically broken across documents 
(e.g., 
auto-opening to content body, preset buttons). The term has worked well in 

that context, but I can see how it might cause confusion given that aria 
already has landmarks. I can't think of a better name, though.

It almost could be rolled up into the table of contents if the toc had 
better semantics. Only the cover might be a problematic use case.

> 7. A non-abstract role name "abstract" is defined immediately after a
> sentence stating: "Abstract roles are used for the ontology. Authors
> must not use abstract roles in content."

This sounds more like a wording fix is in order. That sentence/term 
appears 
somewhat out of the blue, and is confusing as written as there's no 
context 
to what it means, but that shouldn't be reason alone to replace a common 
publishing term, imo.

At the very least, there should be a pointer to where the abstract roles 
are 
defined in the core specification. Any confusion between this singular 
role 
and the plural set should only be short term with more information, I'd 
hope.

Matt