W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2015

Re: Call for Review: Digital Publishing WAI-ARIA Module 1.0 Working Draft

From: Paul Bohman <paul.bohman@deque.com>
Date: Mon, 23 Nov 2015 10:25:29 -0500
Message-ID: <CA+20umGB73dsx06LPgjy1Ggp7QGrYedcChfJQLjvEaU=pVyFTA@mail.gmail.com>
To: Ivan Herman <ivan@w3.org>
Cc: Michael Cooper <cooper@w3.org>, WAI IG <w3c-wai-ig@w3.org>, W3C Digital Publishing IG <public-digipub-ig@w3.org>, "Richard S. Schwerdtfeger" <schwer@us.ibm.com>, Tzviya Siegman <tsiegman@wiley.com>, Markus Gylling <markus.gylling@gmail.com>
That's good that the footmark roles will be allowed elsewhere. Have you
defined how footnotes should act, in terms of discoverability, and a
keyboard interaction model?

By discoverability, I mean if the author writes a linked superscript in the
text, is there a way to know that this is a link to a footnote? I would
think that the screen reader should say something like "link superscript
footnote 1" or something along those lines. And if the user is at the
bottom of the page where the footnotes are, they should hear "footnote 1"
at the start of the footnote. So there are two places where they would need
to know that it's a footnote, but the two instances are not the same role.
One is the link to the footnote. The other is the actual footnote text.

And with regard to keyboard interaction model, I would hope that there
would be a way for users to have the option of either going to the footnote
in the text (moving down to that location), or hearing/seeing the footnote
where they currently are, without having to move focus. It could be in a
tooltip-type popup, for the benefit of sighted keyboard users, but screen
reader users wouldn't need a tooltip. They could use some keyboard method
to have the footnote read to them, with no visible tooltip, by virtue of
the link's programmatic association with the footnote.

There's also another very important aspect of keyboard interaction, which
is the ability to return to the previous spot and have the keyboard focus
actually return to the original link/control. In my recent testing, the
only browser that returned the focus to the original link/control when
using alt + left arrow (on Windows) or command + left arrow (on Mac) was IE
on Windows. Firefox, Chrome, and Safari moved the viewport back up to the
visual area where the focus was, but they did not put the keyboard focus on
the original controller. I realize this is a browser flaw, but it's a bad
one, which breaks keyboard accessibility when trying to return to the
previous location within the same page.

Paul Bohman, PhD
Director of Training, Deque Systems, Inc
703-225-0380, ext.121

On Mon, Nov 23, 2015 at 12:42 AM, Ivan Herman <ivan@w3.org> wrote:

> Paul,
> it is certainly the intention that these roles would be used for any Web
> document, and not only for the area of digital publishing. There is no
> (there shouldn't be, if there is, it is a bug:-) any such restriction in
> the specification nor will there be in the upcoming AT mapping of those
> terms.
> Ivan
> On 22 Nov 2015, at 23:47, Paul Bohman <paul.bohman@deque.com> wrote:
> Will these digital publishing roles be available for use in regular web
> pages? There is a need for things like footnotes, for example, in regular
> web pages, even if they're not in digital publications. I'm thinking of
> footnotes with legal disclaimers, the small print about special offers,
> etc. Will it be frowned-upon to use these new roles in those situations?
Received on Monday, 23 November 2015 15:26:19 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 November 2015 15:26:19 UTC