- From: Paul Bohman <paul.bohman@deque.com>
- Date: Mon, 23 Nov 2015 10:25:29 -0500
- 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>
- Message-ID: <CA+20umGB73dsx06LPgjy1Ggp7QGrYedcChfJQLjvEaU=pVyFTA@mail.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 https://DequeUniversity.com 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:18 UTC