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 indifferent 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