Comments on: Digital Publishing Accessibility Note

Hi everyone,

I volunteered to look at the 'Digital Publishing Accessibility Note’ on the WCAG call today, and I had a bit more time on the train than I anticipated and got quite far through.

My first comment is that the abstract really doesn’t do the document justice, it wasn’t until I got to section 2 that I realised it was aiming to fill in gaps in WCAG (and ATAG/UAAG) for a particular set-of technologies, a bit like the Mobile task-force / extension.  It appears that it could be the basis for new SCs and techniques in WCAG (given the status of ATAG/UAAG). 

It is similar to the initial requirements documents the WCAG extensions are publishing at the moment...

Just as a little background: My experience with non-web publishing is limited. I once went through the process of creating an ebook by hand (HTML to ePub, then mobi conversion), which went ok, but otherwise I’ve just been a consumer of ebooks.

As I went through, the review turned into a process of comparing the requirements against WCAG2. I’m not familiar enough with UAAG2 to do that quickly, hopefully someone else can.

Also, I added some alternative headings in brackets, as some of them seemed misleading, at least from a web-accessibility perspective.

I got down to 2.8 and stopped at “Future work”, if I get time this week I’ll continue.

________________________________________

2.1 Navigating Among Multiple Documents

It notes there is little to address cross-document navigation in WCAG, and suggests adding a discussion of "packaged documents" and author extension to WCAG.

I would note that WCAG aims to fulfil requirements rather than direct solutions. From a web-person’s point of view it appears that:
- Use-case 1 would be solved with a back-button, or a user-agent provided TOC, is that the case?
- Use-case 2 appears to be a miss-linking issue, on the web such an issue would affect everyone, I don’t understand why it would affect a non-sighted reader only?

WCAG’s focus on “web page” as the unit of conformance does make it a little weak on cross-page issues (which are often assumed to be general usability rather than accessibility), but there are some potential places it could be dealt with under the current success criteria.  


For example, Bypass Blocks (2.4.1), Multiple Ways (2.4.5) and Location (2.4.8) could all have new dPub techniques added within the current SC.

________________________________________

2.2 Skippability (hiding repeated content?)

My understanding is that, like most paged media, the user should be able to skip things like headers and page numbers. This seems to fall squarely under WCAG 2: 2.4.1 Bypass Blocks, perhaps with a specific dPub technique?
If it is for personalisation, I guess that fits under UAAG somewhere…  but I couldn’t see an obvious place.
________________________________________

2.3 Escapability (structural navigation?)

My understanding is there is a need to allow users to ‘escape’ (navigate?) to the parent of the current element, or the next sibling. E.g. from a paragraph to the chapter (top), or to the next paragraph. Useful especially for people with a large text size set.

This could possibly be squeezed under 2.1.1 Keyboard operability, but it would be a real stretch. It seems like specific techniques that are associated with UAAG’s structural navigation: https://www.w3.org/TR/UAAG20/#gl-nav-structure

________________________________________

2.4 Page Numbers / Pagination (announcing and navigating by page?)

I appreciate the accessibility implications of needing to know where pages start and end, there is nothing stopping authors from implement something like ePub’s page list:
http://www.idpf.org/accessibility/guidelines/content/nav/pagelist.php 

In the context of an ebook the WCAG2 SC 2.4.8 Location seems more than an AAA requirement, and it is pagination rather than a ‘set of web pages’.

From a UA point of view, I would have thought it is a general requirement to get to specific pages, not just an accessibility one? But that mechanism should be accessible with things like text-size increased etc.

________________________________________

2.5 Phonetic spellings of proper nouns and jargon terms

The request is for "simple pronunciation schemes to be shared among multiple publications”.

 I think this one is a fairly complex issue (if you include internationalisation & language issues) and could do with more input - I am not confident about commenting on this.

Initially, I would be hesitant to suggest a content-producers scheme for this. I appreciate the use-cases, but historically it requires user-agents (mainly screen readers in this case) to be on board, and they haven’t been.

Most (all?) screen readers have their own system for adjusting pronunciations, I think a more-likely solution would be to setup a scheme where pronunciations are shared out to the UA producers, and they are encouraged to compete on being the best for education/business.
________________________________________

2.6 Deeply Nested Heading Levels Best Practices

I can understand that reference books will often have more than 6 levels of heading, I think I got to H4 on my little ebook.
I agree with the suggestion of "Add to WCAG Techniques and to the WAI Tutorials."

However, HTML doesn’t have more than 6 levels (at least in practice), so I’d be interested to know if that is an issue that WCAG can address?
________________________________________

2.7 Semantic List-Head (labelling navigation?)

So the problem is "There is no clear method of associating a title of a list with the list items."
If it were a web page, I’d consider wrapping the list in a <nav>, with an element (usually heading) above the list with aria-labelledby.

However, the comment about that only being available to screenreader users is well taken so it does warrant a discussion about a better solution.

________________________________________

2.8 Drop Cap

"The CSS3 Selector 'First-Letter' allows the creation of accessible drop caps, [but it is] not widely supported in authoring tools"
I agree, I wonder if there are other examples that fit into a more general “support structural authoring” criteria? However, as ATAG is not a separate group anymore, I think it needs some discussion about how that would work, and perhaps a technique adding and discussing with tool implementors. 
________________________________________



That’s it for now, 

-Alastair

Received on Tuesday, 23 February 2016 23:59:47 UTC