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

Charles, every country, state, and local government that has accessibility
compliance criteria require ARIA to meet it for web. That is not the case
for RDFA. This will be even more so by the end of next year as the updated
legislation comes out. This is also not limited to government web sites.
The US ADA will be updated to address public web sites and they are going
to point to the new 508 which is harmonized with WCAG which requires ARIA
for RIAs.

Coga settled on ARIA was that the accessibility community is already
familiar with it and because it has significant uptake.

That is great that RDFa is getting indexed. It is a great technology.




Rich Schwerdtfeger



From: "Chaals McCathie Nevile" <chaals@yandex-team.ru>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: "'Ivan Herman'" <ivan@w3.org>, "'James Craig'"
            <jcraig@apple.com>, "John Foliot" <john.foliot@deque.com>, Lisa
            Seeman/Bethesda/Contr/IBM@IBMUS, "lisa.seeman"
            <lisa.seeman@zoho.com>, "'W3C PF - DPUB Joint Task Force'"
            <public-dpub-aria@w3.org>, "'PF'" <public-pfwg@w3.org>, Siegman
            <tsiegman@wiley.com>
Date: 10/14/2015 12:39 AM
Subject: Re: proliferation of reference roles in the dpub aria spec.



On Tue, 13 Oct 2015 21:33:26 +0200, Richard Schwerdtfeger
<schwer@us.ibm.com> wrote:

What I am suggesting is that we ask the Coga group to take a subset of
ARIA. The Coga group agreed to go the ARIA route vs. RDFA. ARIA has far
greater uptake that RDFA.


For the most part, my proposal isn't that people take up RDFa at all. In a
few cases, where we can demonstrate that it is already used for what COGA
wants on millions of domains (as in, scientifically measured to be more
than 10^6, not just "a lot"), I am suggesting we recognise that reality
instead f trying to convince people to adopt a directly competing approach.

But in the general case I am suggesting that instead of taking up new aria,
trying to convince the world to change how they implement aria, and to
implement something that competes with what people are already doing, COGA
use build on existing HTML.

(RDFa is fast getting to the point where more of the sites indexed by major
search engines have it than not, mostly for opengraph and schema.org. I am
pleased if ARIA is really getting that kind of uptake - but curious where
the figures come from. But that is beside the point).

cheers
Rich Schwerdtfeger

Inactive hide details for "Chaals McCathie Nevile" ---10/13/2015 10:02:25
AM---On Tue, 13 Oct 2015 14:51:38 +0200, lisa.seeman "Chaals McCathie
Nevile" ---10/13/2015 10:02:25 AM---On Tue, 13 Oct 2015 14:51:38 +0200,
lisa.seeman <lisa.seeman@zoho.com>   wrote:

From: "Chaals McCathie Nevile" <chaals@yandex-team.ru>
To: Siegman <tsiegman@wiley.com>, "lisa.seeman" <lisa.seeman@zoho.com>
Cc: "John Foliot" <john.foliot@deque.com>, Richard
Schwerdtfeger/Austin/IBM@IBMUS, "'Ivan Herman'" <ivan@w3.org>, "'W3C PF -
DPUB Joint Task Force'" <public-dpub-aria@w3.org>, "'PF'"
<public-pfwg@w3.org>, Lisa Seeman/Bethesda/Contr/IBM@IBMUS, "'James Craig'"
<jcraig@apple.com>
Date: 10/13/2015 10:02 AM
Subject: Re: proliferation of reference roles in the dpub aria spec.



On Tue, 13 Oct 2015 14:51:38 +0200, lisa.seeman <lisa.seeman@zoho.com>
wrote:

Hi Folks

You can look at an early draft of what COGA are thinking for ARIA at
https://rawgit.com/w3c/coga/master/issue-papers/links-buttons.html

It is an early draft, and we have not yet voted to pass it for wider
circulation, but I think it is worth hearing these kind of comments
earlier.

You can also see a demo of a possible implementation at
http://rawgit.com/ayelet-seeman/coga.personalisation/demo/conactUs.html


What is not mentioned is that the semantics needs to as easy as possible to
use. (The direction of RDFA often raises the bar to high for the Web
Authors we hope to appeal too.)

Yes, that is one concern I had while suggesting that we should piggy-back
on schema.org. On the other hand, being used in millions of domains means
there are a lot of examples out there. And one thing i think the schema.org
folks (which include me) would be very happy about is improving examples on
the site itself, to make them easier to understand and copy.

But for things that can be defined by rel - and for things that *already
are*, like glossary, help, next, previous, start, … the syntax is very
simple. And I suspect we will have fewer typos in rel= than we will in
aria-destination=

(Another theoretical concern with schema is that it is published by 4
companies who can change it at will, based on their own commercial goals -
but I think that is not important in practice, since a vocabulary is really
made by the way it is used. Just as Dublin Core "author" became one of the
most popular terms in metadata, despite never actually existing in Dublin
Core specifications, if a lot of people are using something in schema.org
for something other than search engines, even if we change the formal
schema people can keep doing what they did. The IE6 story shows how hard it
is to change that even for a company with a huge budget and very good
reasons to try…)

cheers



All the best

Lisa Seeman

Athena ICT Accessibility Projects
LinkedIn, Twitter




---- On Tue, 13 Oct 2015 15:37:34 +0300 Siegman<tsiegman@wiley.com> wrote
----
      Piping in from the DPUB side of things. Apologies for the silence,
      several of us were at a workshop last week.





      @rel seems to be made for this, and it came up as an even broader use
      case in the workshop last, which addressed the IDPF’s revision of
      EPUB.





      The one thing that does concern us is that it is a little unclear who
      “owns” the rel registry and how specifically terms are defined.





      Tzviya Siegman


      Digital Book Standards & Capabilities Lead


      Wiley


      201-748-6884


      tsiegman@wiley.com





      From: John Foliot [mailto:john.foliot@deque.com]
      Sent: Monday, October 12, 2015 6:52 PM
      To: 'Richard Schwerdtfeger'
      Cc: 'Ivan Herman'; 'W3C PF - DPUB Joint Task Force'; 'PF'; 'Lisa
      Seeman'; 'Chaals McCathie Nevile'; 'James Craig'
      Subject: RE: proliferation of reference roles in the dpub aria spec.





      Hi Rich,





      Chiming in here, I have to agree with Chaals, the @rel attribute does
      (is intended to do) exactly what you are talking about.





      Having a new series of @rel values (dpub.foo or coga.foo) would be
      consistent with existing technology/techniques today. In fact,
      related to one requirement from the dpub folks, there is already a
      “brainstorm” proposal for rel=”bibliography” in the wiki:
      http://microformats.org/wiki/existing-rel-values (nearer the end of
      the document).





      I’ll also point out to Chaals that better implementation of @rel *
      could* also serve as an alternative to @accesskey (
      http://john.foliot.ca/link-relationships-as-an-alternative-to-accesskeys

      ) in that a standardized list of @rel values would also be useful for
      end-users to map accesskey-like behaviors to, using keystroke
      combinations *the user* chooses (as opposed to the author, who will
      likely get it wrong as often as right). J





      Finally, the fact that new values can (could) easily be added to a
      standardized list is extremely useful, although I question the use of
      a public wiki for that, as perhaps being a little too informal a
      mechanism to record what would be essentially mission-critical values
      moving forward (i.e. anyone could add, remove or edit values with no
      actual process/security net behind that). I vaguely recall this being
      a point of discussion quite a while back, however, to date I will
      also note that this type of possible abuse has not (yet) manifested,
      so perhaps I am overly concerned about nothing…





      I will also reiterate my concern that currently ARIA is suffering
      from a ghettoization of sorts, in that it is seen as *only* for
      Assistive Technology such as screen readers, which is an unfortunate
      but real reality today.





      JF





      From: Chaals McCathie Nevile [mailto:chaals@yandex-team.ru]
      Sent: Monday, October 12, 2015 4:45 PM
      To: James Craig <jcraig@apple.com>; Richard Schwerdtfeger <
      schwer@us.ibm.com>
      Cc: Ivan Herman <ivan@w3.org>; W3C PF - DPUB Joint Task Force <
      public-dpub-aria@w3.org>; PF <public-pfwg@w3.org>; Lisa Seeman <
      lseeman@us.ibm.com>
      Subject: Re: proliferation of reference roles in the dpub aria spec.





      Hi RIch,





      I think we are still talking past each other.





      It sounds like the COGA group is looking for an attribute whose
      values can be defined, in a list that can be easily extended, that
      can describe links in a machine-readable way.





      HTML has an attribute for that called rel. It has been around for a
      long time, has been implemented in various ways all the way through
      different bits of the toolchain - and even beyond the Web, for
      whatever that is worth.





      There is also "rev" but the only value of that is where you want to
      reduce the number of possible values - instead of having to have
      rel="next" and rel="previous" you could use rel="next" but rev="next"
      to say that something else had rel="next", i.e. is the previous
      document.





      More detail below.





      On Mon, 12 Oct 2015 22:40:18 +0200, Richard Schwerdtfeger <
      schwer@us.ibm.com> wrote:
      That is not the issue and it has absolutely nothing to do with the
      problem we are trying to solve which is that given a link we need to
      know what the destination type of the link it is going. This was
      discussed at the last ARIA task force meeting. It is important that
      people read the work going on in the cognitive accessibility task
      force and what is being done with dpub.


      Can you please provide some clearer sense of what we need to read?
      "All of coga" isn't useful, some list of  15 wiki pages and 20 email
      threads from the last 4 months might be more rational.
      Coga needs to know that that link points to help information


      This is *exactly* the sort of thing rel does.


      In the HTML4 era  browsers provided those buttons in consistent
      places such as at the top or bottom of the window, triggered by
      rel="help", rel="next", etc, as per the spec:
      http://www.w3.org/TR/1998/REC-html40-19980424/types.html#type-links






      The HTML5 version appears to have less, since it defers to the wiki
      which allows anyone to list a rel value and the spec for it, but it
      explicitly includes help, prev and next ...
      and a whole list of other features such that when styled they know
      the purpose of the destination of the link so it can be styled using
      symbols or other mechanisms so that they can appear in a consistent
      way.


      Yes, but any attribute can be used for styling.
      This impacts aging, in that many web sites and applications style
      things differently and the user gets lost. The dpub group had
      introduced different roles for things like glossary references that
      could easily marked with role="link" and
      aria-destination="glossaryterm". A publisher could style these to
      look the same way and in a way that is easily understood by different
      users.


      indeed:


        *[role=link][rel=next] { /* your style for next */ }


        *[role=link][rel=glossary]:before { /* your dictionary icon */ }
      Coga has suggested the use of an new aria-destination attribute that
      could consume these values. This would allow us to still reuse the
      link role for these different types of links but then provide
      additional information that would help drive toward a consistent look
      and feel. @rel would be great but unfortunately HTML shoved a bunch
      of totally unrelated values in it.


      You don't need to handle irrelevant values. But for anything that
      needs a particular behaviour, such as a link tothe next thing, or a
      link to help, you have to implement it whatever attribute it is in.





      The nice thing about doing this on rel attributes is that you build
      on a set of browser extensions, content, and tools that link content,
      stretching back more or less the whole history of the Web.





      More to the point, some of the attributes you think are irrelevant
      match the things I have read from COGA (although I may have
      misunderstood something).





      rel="stylesheet alternate" title="simplified layout"


      rel="alternate" hreflang="en-x-kincaid-level-4" title="Easy to read"





      These are things that real developers already know how to do. And
      things that are relatively easy to crawl for. Which matters, because
      *finding* resources that are useful is also an important way to
      improve accessibility.





      Building on existing HTML to enable for example





      <a rel="icon"


      <span role="link" onclick="popupDictionary(this.innerText)"
      rel="glossary"





      Would actually be very easy. I'd be very happy to do that in the Web
      Platforms group, which is the new successor to both Web Apps and
      HTML, at the same time as following the existing trivial process of
      editing the wiki that HTML5 uses for extending values.
      This would be for the link role and not the <link> element. The user
      experience could care less if the @rel="prefetch". @rel is a hodge
      podge of unrelated values.


      rel is currently applicable to link, a and area elements - because
      those are the things that define links in HTML. It makes perfect
      logical sense to argue that something with role="link" is analagous
      to an a element, and therefore the rel attribute should be valid, and
      have the same behaviour as it does for the a element.
      Charles had earlier asked how ATs processed @rel. On Windows, at
      least, they don't and that may be because many of the values have no
      value to ATs.


      Sure. But nor does anything in existence process the aria-destination
      attribute. Which puts it behind rel, since there are browsers in use
      which handle it. In any case, implementation is relatively simple...





      var helpButton = document.querySelector('[role=link][rel=help], a
      [rel=help], area[rel=help]');





      document.addeventListener('help', helpButton.click);





      Although most browsers don't emit a "help" event for pages so you
      might want to define something temporary like a keyboard listener for
      'f1' or add a button to the document (like ReSpec does for W3C
      working drafts).
      Making matters worse SVG2 doesn't even have a rel attribute:
      https://svgwg.org/svg2-draft/attindex.html



      But nor does it have an aria-destination attribute. In any event,
      implementation is pretty much the same whatever it is called.
       So, I was interested in @rel as well but the solution quickly felt
      apart for our purposes.


      I don't think it does. Your purpose is *exactly* what the rel
      attribute was intended to do, and has done for a couple of decades.
      Making a *different* attribute to do the same thing seems like a bad
      way forward. It introduces confusion, or double the work, at best.
      I have not seen the SVG WG indicate that it will adopt the HTML <a>


      It has an a element of its own. Adding a rel attribute as valid on
      that is pretty trivial as far as I can tell, whether they adopt the
      HTML element or not.
      In studies with the aging population with NIDDR and in the Coga task
      force that senior users want the user interface to be consistent in
      how it looks and where things are placed. For example, they don't
      want the next link to appear in
      different places as they just can't process the site. They get
      confused.


      This is exactly what the rel="next" attribute was used for by
      shipping browsers, which placed it near the "contents", "previous",
      "help" and "index" buttons.





      You might want to ask the browsers why they removed those, and how
      hard it is to put them back (hint: trivial, although it would be good
      if they doubled the time allowed to a week, to get some decent design
      applied this time)
      Consequently, we are talking about an aria-destination attribute. I
      have cc'd Lisa Seeman if you have any questions from the Coga task
      force.


      1. Does COGA care what the attribute is called?


      2. Does COGA believe that


         a. this attribute should *only* be relevant to people using
      "specialised" technology, and


         b. the attribute should not be processed to modify the user
      interface of mainstream browsers?





      (and repeating the request I started with, what do I need to read on
      this topic?)





      cheers





      Chaals





      --


      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





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