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 21:01:59 -0500
Message-ID: <CA+20umFwTCzXJZQo210hsoW7_ZqQG==-_364u8kustRp5mZaog@mail.gmail.com>
To: "Siegman, Tzviya - Hoboken" <tsiegman@wiley.com>
Cc: Ivan Herman <ivan@w3.org>, 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>, Markus Gylling <markus.gylling@gmail.com>
Thanks for the additional information. I can see why adding a role to a
link would be problematic. The role would override the link role, at least
if we go by the standard use of roles in ARIA.

It seems to me that we could avoid that problem by using a non-role
attribute like:

<a href="#id123" aria-noteref="id123">Footnote 123</a>

I assume that this type of syntax has been explored. Was it rejected? If
so, I'd like to hear the logic behind the decision.


Paul Bohman, PhD
Director of Training, Deque Systems, Inc
703-225-0380, ext.121
https://DequeUniversity.com


On Mon, Nov 23, 2015 at 6:34 PM, Siegman, Tzviya - Hoboken <
tsiegman@wiley.com> wrote:

> Hi Paul,
>
>
>
> We have defined a “noteref” role [1], but you’ll note that there is an
> issue in the document regarding that role as there is still some discussion
> about the best approach.
>
>
>
> It would be helpful if you would file an issue on the GitHub repository
> [2] if there is something specific you’d like to see. Please note that we
> will publish the First Public Working Draft of the Mappings for
> Accessibility  APIs for DPUB-ARIA shortly.
>
>
>
> [1] http://www.w3.org/TR/dpub-aria-1.0/#doc-noteref
>
> [2] https://github.com/w3c/aria/issues
>
>
>
> *Tzviya Siegman*
>
> Digital Book Standards & Capabilities Lead
>
> Wiley
>
> 201-748-6884
>
> tsiegman@wiley.com
>
>
>
> *From:* Paul Bohman [mailto:paul.bohman@deque.com <paul.bohman@deque.com>]
>
> *Sent:* Monday, November 23, 2015 10:25 AM
> *To:* Ivan Herman
> *Cc:* Michael Cooper; WAI IG; W3C Digital Publishing IG; Richard S.
> Schwerdtfeger; Siegman, Tzviya - Hoboken; Markus Gylling
> *Subject:* Re: Call for Review: Digital Publishing WAI-ARIA Module 1.0
> Working Draft
>
>
>
> 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 Tuesday, 24 November 2015 02:02:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 24 November 2015 02:02:54 UTC