Re: proliferation of reference roles in the dpub aria spec.


Good point Charles. To my knowledge AT Vendors do not look at @rel.

The problems I have with it are that many of its values and the fact that
it applies to an area.

http://rawgit.com/w3c/aria/master/aria/dpub.html#dpub-glossref


Here are some useless values, and confusing values, to our audience:
prefetch, stylesheet, bookmark, license, stylesheet

Why would a cognitively impaired user care that it maps to a stylesheet?

Rich


Rich Schwerdtfeger



From: "Chaals McCathie Nevile" <chaals@yandex-team.ru>
To: "Ivan Herman" <ivan@w3.org>
Cc: "W3C PF - DPUB Joint Task Force" <public-dpub-aria@w3.org>,
            Richard Schwerdtfeger/Austin/IBM@IBMUS, PF <public-pfwg@w3.org>
Date: 10/09/2015 06:41 AM
Subject: Re: proliferation of reference roles in the dpub aria spec.



On Fri, 09 Oct 2015 11:53:16 +0200, Ivan Herman <ivan@w3.org> wrote:

AFAIK (and per[1]), the acceptable link type (a.k.a. possible values for
@rel) are registered through the microformat wiki page[2]. Do we have
enough information on whether this registration mechanism really works well
for implementers? How easy/difficult is it to add new @rel values if so
required? Just to take examples from this thread, rel=biblioentry is
labelled as "dropped" (ie, not to be used), and rel=glossentry is
unregistered. I must admit I do not know how [3] functions in practice.

I haven't tried it myself, but ti would be worth doing... because if that
doesn't work, HTML had better rethink its approach in general, not just for
the tiny population of screenreader users who can do something with aria.

And I also do not know how AT's take @rel values into account (if at all).

Like browsers in general: woefully as a rule, with some honourable
exceptions like rel="stylesheet".

I do not have any strong opinion, just not clear what the mechanism is in
practice…

If we're minting attribute values, it seems immaterial what the attribute
is called. But using rel for purpose seems to make more sense than
multiplying aria - especially while aria is still regarded by mainstream
browsers as "I connect the aria to the thing in the accessibility API and
then it's someone else's problem".

cheers


Ivan

[1] http://www.w3.org/TR/html5/links.html#linkTypes

[2] http://microformats.org/wiki/existing-rel-values





      On 09 Oct 2015, at 10:24 , Chaals McCathie Nevile <
      chaals@yandex-team.ru> wrote:

      On Fri, 09 Oct 2015 02:17:09 +0200, Richard Schwerdtfeger <
      schwer@us.ibm.com> wrote:

      As I said, I have had somewhat of a concern about the numerous
      definition of roles that are essentially links. The Coga task force
      wants to introduce and aria-destination attribute for links to create
      standard destinations users would go to to enable consistent style of
      the UI for familiarity to the user.

      See the aria-destination attribute from coga:
      https://rawgit.com/w3c/coga/master/issue-papers/links-buttons.html


      So for these roles I would prefer to have:

      <div role="link" aria-destination="biblioentry"> as opposed to
      http://rawgit.com/w3c/aria/master/aria/dpub.html#dpub-biblioref


      similarly:

      <div role="link" aria-destination="glossentry" as opposed to
      http://rawgit.com/w3c/aria/master/aria/dpub.html#dpub-glossref


      This would cause us to start folding in some of the coga features
      into ARIA 1.1.

      Feedback? Coga has similar needs.


      This is what the rel= attribute is for. Which makes it easier to
      extend the functionality without needing an assistive tech plugged in
      to the accessibility API.

      cheers


      Rich



      Rich Schwerdtfeger





      --
      Charles McCathie Nevile - web standards - CTO Office, Yandex
      chaals@yandex-team.ru - - - Find more at http://yandex.com



----
Ivan Herman, W3C
Digital Publishing Lead
Home: http://www.w3.org/People/Ivan/

mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704








--
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Friday, 9 October 2015 13:32:06 UTC