Re: Issue-742: Proposal aria-destination

On Fri, 16 Oct 2015 09:10:18 +0200, Schnabel, Stefan  
<stefan.schnabel@sap.com> wrote:

>
> Hi Chaals,
>
>
>>>> Terms and Conditions<a href="#footnote" aria-label="Footnote:  
>>>> 1"><sup>[1]</sup></a>
>
>>>>> …
>
>>>>> That the COGA people are explicitly asking for machine-readable  
>>>>> terms to do automated processing. (As I believe DPub are doing).
>
>
> Is aria-label NOT machine readable? We always check that in our  
> automatic accessibility checks..

I mean the content of the attribute will be identifiable by a machine - in  
practical terms, it comes from an enumerated set of value, rather than  
being free text.

You might check there *is* an aria-label, but do you have a way of  
automatically that "wot eye sees" and "the visual representation generated  
by my perceptive capacity" are the same, but that "what? I see" is likely  
to be very different?

In any event, their first stated use case is to enable third parties to  
write reliable CSS selectors such as

*[rel=help]:before { content: url(HelpIcon)}

and have it pick up links, buttons, spans with a bunch of javascript and  
rel="help", rather than having to use a pile of heuristics.

Note. This means people writing content for russian would be expected to  
use rel="help" not rel="Помочь" …  but if they do that, their russian  
content (or hebrew, german, spanish, etc) will get the HelpIcon rendered  
next to the thing that links to help, whatever it looks like.

cheers

Chaals

>
>
> Regards
>
> Stefan
>
>
> From: Chaals McCathie Nevile [mailto:chaals@yandex-team.ru]Sent:  
> Freitag, 16. Oktober 2015 01:56
> To: 'Richard Schwerdtfeger'; John Foliot
> Cc: 'PF'
> Subject: Re: Issue-742: Proposal aria-destination
>
>
> On Thu, 15 Oct 2015 22:12:46 +0200, John Foliot <john.foliot@deque.com>  
> wrote:
>>
>> 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?
>
> That the COGA people are explicitly asking for machine-readable terms to  
> do automated processing. (As I believe DPub are doing).
>
>
>
>>
>> From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com]The meta data  
>> @rel is important because we would need to define a strategy to map it  
>> to AT if necessary.
>
>
> Agreed. THe key here is "if ncessary". You only need to care about rel  
> values relevant to accessibility - and we can (and IMHO should) write a  
> spec that singles those out and suggests >appropriate implementation  
> patterns.
>
>
>
>>
>> ... 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.
>
>
> OK. Part of the issue I see is that there is a pretty nasty  
> architectural ugliness in having two different ways fo doing the same  
> thing - one of which is for "accessibility" and one of which is for  
> >"everyone else".
>
>
> Anyway, I am hoping to discuss it at TPAC - in part because I think  
> there are some clear lessons for HTML about some things that need to be  
> tweaked...
>
>
> cheers
>
>
>>
>>
>>
>>>> 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> wrote:
>>
>> From: "Chaals McCathie Nevile" <chaals@yandex-team.ru>
>> To: Richard Schwerdtfeger/Austin/IBM@IBMUS
>> Cc: PF <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> 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> wrote:
>>
>>>> From: "Chaals McCathie Nevile" <chaals@yandex-team.ru>
>> To: PF <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> 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
>>>
>>> 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) 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
>> [2]
>> http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions
>> [3] http://microformats.org/wiki/rel-home
>> [4] http://microformats.org/wiki/rel-sitemap
>> [5] http://www.w3.org/TR/html5/links.html#link-type-help
>> [6] 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 - - - 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



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