Re: Issue-742: Proposal aria-destination

tokens. Why would anyone label something Footnote: 1. That is how people
used to hack accessibility, in the early 90s, by shoving all the semantics
into a label. e.g. aria-label"checkbox checked".

How this should be done is:

 Terms and Conditions<a href="#footnote"
aria-destination="footnoteref"><sup>[1]</sup></a>

Sorry Charles but that is dreadful.




Rich Schwerdtfeger



From: "Chaals McCathie Nevile" <chaals@yandex-team.ru>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS, "John Foliot"
            <john.foliot@deque.com>
Cc: "'PF'" <public-pfwg@w3.org>
Date: 10/15/2015 06:56 PM
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

Inactive hide details for "Chaals McCathie Nevile" ---10/13/2015 07:07:39
PM---On Wed, 14 Oct 2015 00:23:07 +0200, Richard Schw"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

Inactive hide details for "Chaals McCathie Nevile" ---10/13/2015 06:15:00
AM---On Mon, 12 Oct 2015 23:39:34 +0200, Richard Schw"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