W3C home > Mailing lists > Public > public-publ-wg@w3.org > September 2017

RE: [a11y] comments on the navigation requirements

From: White, Jason J <jjwhite@ets.org>
Date: Thu, 7 Sep 2017 13:23:55 +0000
To: Avneesh Singh <avneesh.sg@gmail.com>, Romain <rdeltour@gmail.com>, W3C Publishing Working Group <public-publ-wg@w3.org>
Message-ID: <BN6PR07MB3457A7254A773E2C305FECDDAB940@BN6PR07MB3457.namprd07.prod.outlook.com>
I read Romain's comments as seeking desirable and legitimate clarification of the material rather than as attempting to turn it into a precisely specified set of requirements.

> -----Original Message-----
> From: Avneesh Singh [mailto:avneesh.sg@gmail.com]
> Sent: Thursday, September 7, 2017 4:43 AM
> To: Romain <rdeltour@gmail.com>; W3C Publishing Working Group <public-
> publ-wg@w3.org>
> Subject: Re: [a11y] comments on the navigation requirements
>
> Hi Romain,
>
> Thanks for the list.
> As discussed in yesterday's call, we should not try to over specify things in this
> document because this is at the conceptual level.
> Surely clarifications will help at places, and we should do it.
> We should also add missing concepts.
>
> But we should not try to make it something like WCAG principles and success
> criteria.
> We should add a note regarding this at the top, so that readers are aware of it.
>
> With regards
> Avneesh
>
> -----Original Message-----
> From: Romain
> Sent: Thursday, September 7, 2017 14:01
> To: W3C Publishing Working Group
> Subject: [a11y] comments on the navigation requirements
>
> Hi a11y TF,
>
> Following yesterday's call, here are my comments on the "Description of
> Accessibility Requirements for WP" wiki document, before we share to a larger
> audience.
>
> The following comments were mentioned in the call, I re-state them here for
> completeness:
>
> - I find that "accessible to readers" and "machine readable" (used in several
> places) are a bit confusing. Especially "accessible to readers":
> does it mean accessible in a browser, or in a WP-aware reading system, or
> something else?
> My suggestion is to see if we can use instead the concept of "accessibility
> supported", which is well-defined in WCAG.
>
> - the sentence "The information about hierarchy of sections must be preserved
> in WP" is not very clear to me. As suggested by Matt, one requirement is that
> "WP needs to define a way to express hierarchical content in a sequence of
> documents". I also agree with George that the issue isn't just about accessibility,
> but is a larger one: what does it mean for a document to be part of a web
> publication? is there an API to see the publication as a whole? etc.
>
> The next comments are about the "navigation and default reading order"
> section:
>
> - what is meant by "navigation" in this section? does it mean "linked in the ToC"
> or can it include the other various ways to reach content in a publication (e.g.
> from list of pages, from a site map, from next/previous links, etc).
>
> - The first bullet says:
> > Ideally navigation to all content resources is required, but there can
> > be some flexibility in some situations.
>
> what are these situations ? the current wording is not very precise, so as-is it can
> (and will) be interpreted as "navigation to all content resources is not required".
>
> We might come up with rules like "if a document has a heading, it must be linked
> from the ToC", but it would be an a11y guideline rather than something defined
> in the spec.
>
> > If there is default reading order which lists all the content
> > resources then author can be given flexibility to exclude some content
> > resources from navigation.
>
> This requirement doesn't add much from the previous bullet, which already said
> that some content resources could be excluded. Is it meant to be a refinement
> of the first?
> Does it mean
> - "If the default reading order lists all the content resources, the ToC is
> optional"?
> - OR "If a content resource is in the default reading order, it doesn't have to be
> linked in the ToC"?
> - OR "if a content resource can be accessed in a natural reading order, if doesn't
> have to be linked in the ToC"?
> - OR something else?
>
> > If default reading order does not cover all content resources (e.g.
> > decision tree based traversal in publication) then access to all the
> > content resources has to be ensured with navigation.
>
> That's interesting: let's consider a publication with most of its content outside
> the default reading order (e.g."chose your own adventure").
> Does all the content need to be *directly* accessible from a top-level
> navigation, or is it enough to be somehow reachable from *a* natural reading
> order?
> (Note: I'm using "natural reading order" to describe a reading order that is a
> natural reading sequence, if not the default one.) There's also the author's
> intent, who might want to hide some content until some reading is done.
> Wouldn't that be in conflict with this requirement?
>
> > For the resources in default reading order, continuous reading
> > experience is required. In other words, the user should be able to
> > move from end of a content resource to the next resource without going
> through TOC again.
>
> Good. Here particularly, using "accessibility supported" may free us of the
> "browser vs. RS" debate.
>
> > In all the above scenarios, user agent should be able to inform users
> > about their current reading location in WP.
>
> This is SC 2.4.7., plain and simple. We should say if there's anything specific to
> WP here.
>
> Thoughts welcome!
> Romain.
>
>
>


________________________________

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.


Thank you for your compliance.

________________________________
Received on Thursday, 7 September 2017 13:24:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:49:06 UTC