RE: Issue-742: Proposal aria-destination

Hi Rich,

 

You’ve noted that the values may have to be mapped to the accessibility APIs. As what? 

 

Again, if aria-destination is what we are looking at, it strikes me that what you are after is a better (accessible) description of where the link goes to, so that it is more 'useful' to screen readers (as after all, the functionality is already clear - it's a link). 

 

We can do that today with existing ARIA constructs, and it is an authoring issue rather than a mapping/new functionality issue:

        Terms and Conditions<a href="#footnote" aria-label="Footnote: 1"><sup>[1]</sup></a>

 

What am I missing?

 

JF

 

From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com] 
Sent: Thursday, October 15, 2015 2:47 PM
To: Chaals McCathie Nevile <chaals@yandex-team.ru>
Cc: PF <public-pfwg@w3.org>
Subject: Re: Issue-742: Proposal aria-destination

 

Charles, 

The meta data @rel is important because we would need to define a strategy to map it to AT if necessary. 

... regarding the Web being ugly that does not mean we need to make it more ugly. We discussed the @rel attribute on the ARIA call and there are a lot of concerns about it being a kitchen sink of meta data related to the prior sentence. That may be where the group goes but that is still to be determined. 

Rich


Rich Schwerdtfeger

"Chaals McCathie Nevile" ---10/13/2015 07:07:39 PM---On Wed, 14 Oct 2015 00:23:07 +0200, Richard Schwerdtfeger   <schwer@us.ibm.com <mailto:schwer@us.ibm.com> > wrote:

From: "Chaals McCathie Nevile" <chaals@yandex-team.ru <mailto:chaals@yandex-team.ru> >
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: PF <public-pfwg@w3.org <mailto:public-pfwg@w3.org> >
Date: 10/13/2015 07:07 PM
Subject: Re: Issue-742: Proposal aria-destination

  _____  




On Wed, 14 Oct 2015 00:23:07 +0200, Richard Schwerdtfeger <schwer@us.ibm.com <mailto:schwer@us.ibm.com> > wrote:

@rel is not in SVG. 

Nor is aria-destination.
rel="start" is innocuous   

Who came up with this meta data in rel. A lot of it is dreadful. 

So what? A lot of the stuff that is fundamental to the Web is dreadful. If you only have to look at the things that are relevant to your use case, it is easy to describe the list of things you care about, get implementation of those, and leave the rest to whatever audience and fate it gets.

That seems a lot easier than trying to convince the people who are already doing that, in cases that are relevant to DPub and cognitive accessibility, that they should suddenly rebuild their entire toolchain, and replace all the content they use, to satisffy people who haven't started implementing anything in production yet.

cheers

Chaals



Rich Schwerdtfeger

"Chaals McCathie Nevile" ---10/13/2015 06:15:00 AM---On Mon, 12 Oct 2015 23:39:34 +0200, Richard Schwerdtfeger <schwer@us.ibm.com <mailto:schwer@us.ibm.com> > wrote:

From: "Chaals McCathie Nevile" <chaals@yandex-team.ru <mailto:chaals@yandex-team.ru> >
To: PF <public-pfwg@w3.org <mailto:public-pfwg@w3.org> >, Richard Schwerdtfeger/Austin/IBM@IBMUS
Date: 10/13/2015 06:15 AM
Subject: Re: Issue-742: Proposal aria-destination

  _____  




On Mon, 12 Oct 2015 23:39:34 +0200, Richard Schwerdtfeger
<schwer@us.ibm.com <mailto:schwer@us.ibm.com> > wrote:

> This is not a formal proposal but one that would seed a formal proposal  
> if the group agrees. I would need to coordinate with coga and the  
> aria-dpub folks. Normally I would push this to ARIA 2.0 but because we  
> have two efforts wanting essentially the same thing and I don't want to  
> have multiple roles for a link I believe this is a better approach.
>
> aria-destination - Provides the context of a link.
>
> This attribute provides contextual semantics for the destination of a  
> link so that authors may use this information to drive a consistent user  
> interface. Some assistive technologies may this information important to  
> provide to assistive technologies.
>
> The following is a list of possible values that the destination could  
> take on from the coga task force and I suggest we consider a subset of  
> these:

> * home

Does this mean a home page? If so, it is covered by the existing
rel="start" which is already in HTML 4 [1] and in HTML5 through being
listed in the microformats wiki [2]. The proposed rel="home" [3] seems to
be a synonym.

> * sign in
> * sign up

These values should be proposed for rel. The HTML specifications have
traditionally suggested the address element for these, but it is
insufficiently clear what the content means.

> * site map

This is covered by the proposal for rel="sitemap" [4] to be included in
HTML5.

> * help

This is already part of HTML5 [5] as rel="help"

> * terms

Does this mean license, which is already in HTML5 [6], or something else?

> * comment
> * language (English)
> * post
> * social (provide label - such as facebook twitter)
> * tools

Can you explain what these are meant to do, or provide a pointer to where  
they are described or discussed in more detail? It is pretty hard from the  
standalone page linked to understand

> * about us
> * contact us
> * our email
> * our phone
> * product
> * services

These things are already covered by the widely used schema.org,  
*currently* used on millions of domains. It makes more sense to read that  
existing markup than to try and build a parallel version


> This is based on this wiki:  
>  <https://rawgit.com/w3c/coga/master/issue-papers/links-buttons.html> https://rawgit.com/w3c/coga/master/issue-papers/links-buttons.html
>
> I introduce this now as the dpub aria task force roles for different  
> types of links which reflect the destination of the link provided. Since  
> both task forces need a feature like this we should place an anchor  
> inside ARIA 1.1 so that they mau build off it.

Instead of doing that, I suggest putting this in HTML itself, except for  
the cases where schema.org seems to have a significant mind-share and  
deployment already.

> The current Digital Publishing WAI-ARIA module  
> ( <http://rawgit.com/w3c/aria/master/aria/dpub.html> http://rawgit.com/w3c/aria/master/aria/dpub.html) has these roles:
>
>
> doc-biblioref: A reference to a bibliography entry.
> doc-glossref: A reference to a glossary definition

Both of these are readily covered - glossary by the existing rel value,  
biblioref by retrieving the proposal that wasn't accepted for HTML 4.

> doc-location: A link that allows the user to jump to a related location  
> in the content (e.g., from a footnote to its reference, from an index  
> entry to where the topic is discussed, or from a glossary definition to  
> where the term is used).

The footnote use case can easily be covered with the existing rel="prev" /  
rel="previous".

For an index entry this makes less sense, as it is very common that there  
will be multiple places a term appears.

An alternative approach would be to use the rev attribute for this case,  
as this seems to be a pretty sound use case.

> doc-noteref: A reference to a footnote, typically appearing as a  
> superscripted number or symbol in the main body of text.

This can readily be covered by retrieving the proposed rel="footnote".

> I recommend these be additional tokenized values, without the doc-, for  
> aria-destination and a subset of what coga would like for ARIA 1.1. The  
> Coga task force can then expand on the values.
>
>
> example:
>
> style {
>
> a[a[aria-destination="glossref"] {

*[rel=glossary] {

Also covers the case where you have role="link" instead of a real link,  
and the now mostly legacy case of image maps, instead of using multiple  
CSS declarations

>    background-color: yellow;
>
>    border: 2px blue;
>
> }
> div[role="link"][aria-destination="glossref"] {
>
>    background-color: yellow;
>
>    border: 2px blue;
> }
>
>
>
> <a aria-destination="glossref" href="..." >discombobulated</a>

<a rel="glossary" href="…"

already exists in the wild, but I am not sure how common it is.

[1]  <http://www.w3.org/TR/html4/types.html#h-6.12> http://www.w3.org/TR/html4/types.html#h-6.12
[2]
 <http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions> http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions
[3]  <http://microformats.org/wiki/rel-home> http://microformats.org/wiki/rel-home
[4]  <http://microformats.org/wiki/rel-sitemap> http://microformats.org/wiki/rel-sitemap
[5]  <http://www.w3.org/TR/html5/links.html#link-type-help> http://www.w3.org/TR/html5/links.html#link-type-help
[6]  <http://www.w3.org/TR/html5/links.html#link-type-license> http://www.w3.org/TR/html5/links.html#link-type-license

cheers

Chaals

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






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