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

No this is not correct. Again, the only thing we care is that properties
like aria- don't break assistive technologies.

What I see is that the aria-destination would drive styling in this
scenario. Screen readers may not even care about the value.

What is clear is that values like prefetch and stylesheet should not be
values that drive the user experience through styling. My concern is
bolting something on to an attribute that can take a broad range of
solutions trying to address unrelated problems. This leads to confusion.

Rich


Rich Schwerdtfeger



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



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

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?


Why would anyone try to present to a cognitively impaired used that
something maps to a stylesheet? And what is helpful to people with
cognitive disabilities about "footer", until you actually implement some
useful behaviour around it?

Browsers already have built-in handling for everyone of rel="stylesheet" -
they use it to present content in a way that enhances the basic structural
information with a useful visual style. And different, but equally useful
handling of prefetch.

Why wouldn't they do something useful with other values of rel, that they
would do if it were called aria-something?

The only argument I can see for using aria-* is that it forces the issue of
whether you need to be using an assistive technology for aria to help you.
But I doubt there is any real value there to outweigh the problems we get
by shifting everything - including a lot of our hopes for making things
work better as well as a confusing pile of markup - onto aria.

cheers


Rich


Rich Schwerdtfeger

Inactive hide details for "Chaals McCathie Nevile" ---10/09/2015 06:41:58
AM---On Fri, 09 Oct 2015 11:53:16 +0200, Ivan Herman "Chaals McCathie
Nevile" ---10/09/2015 06:41:58 AM---On Fri, 09 Oct 2015 11:53:16 +0200,
Ivan Herman <ivan@w3.org> wrote: > AFAIK (and per[1]), the accep

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




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