W3C home > Mailing lists > Public > public-html@w3.org > May 2015

Re: ARIA use in HTML other than for accessibility.

From: Henri Sivonen <hsivonen@hsivonen.fi>
Date: Tue, 12 May 2015 14:35:03 +0300
Message-ID: <CAJQvAudOb5u3e8NaW_TB6naP5TEqcKJAy=qCgynH-0PQf-nQDw@mail.gmail.com>
To: Shane McCarron <shane@aptest.com>
Cc: "Michael[tm] Smith" <mike@w3.org>, "public-html@w3.org" <public-html@w3.org>
On Sat, May 2, 2015 at 6:28 PM, Shane McCarron <shane@aptest.com> wrote:
> These people are domain experts representing the
> largest publishers in the world.
> Who are you, I, or the HTML working group
> to say they are wrong about what their constituents need?

I think by now we should recognize that the vision for semantic markup
where you mark up identifiable structures without regard to how the
receiving software responds to these structures having been marked up
and wonderful effects blooming as a result does not really work. In
particular, that approach is not sufficient for making the bulk of
content be marked up consistently enough for any piece of software to
be able to rely on structures for which markup exists actually having
been marked up using the features that exist.

On the other hand, when Web authors have a good idea what sort of
concrete behavior they are eliciting from receiving software when
using a particular piece of markup, there's a better payoff per unit
of effort invested into marking things up.

Large publishers may be very good at cataloging what kind of
identifiable structures existing books, but it doesn't follow that it
is actually useful for receiving software for those structures to be
marked up in a standardized way. As anecdote, I have an EPUB reader
from a well-known vendor (Kobo Glo) and as far as I can tell the user
interface does not make useful use of even the full range of
structures expressible in EPUB2.

Having a large gap between the semantics in the spec and the semantics
actually put to use by the consuming software is a pretty strong hint
of YAGNI. And even if it isn't, it's generally a good idea not to let
the spec get too far ahead of implementations. (HTML5 has had success
by slowing down at times to let implementations catch up and XHTML2
failed when it when in its own direction without regard to where the
implemenations were.) So if anything, I think it would make sense to
pause to see how the features present in EPUB2 and EPUB3 get
implementations instead of having the spec pipeline produce more
semantics at full speed.

>> > I appreciate that there are some in the HTML community who feel that the
>> > use of values for @role should be constrained.
>> It’s not just “some in the HTML community”—it’s the as-defined HTML
>> language which is making those constraints, as documented in the HTML
>> spec.
> I know.  And I also know it was a vocal few who made this happen, and that
> the PFWG rolled over and agreed because they had little choice.  That
> doesn't make it right.  It just makes it the status quo.

The PFWG is supposed to work on accessibility and not Semantics.

As for "making it right", the W3C closed down the XHTML2 Working
Group. I think this should be taken as a rejection of the vision of
the XHTML2 Working Group, including for the role attribute and RDFa,
instead rehashing the same ideas over and over in other working
groups, such as the HTML WG or the PFWG.

I agree with Steve and Mike that there is value in not confusing the
purpose of the role attribute with non-accessibility scope creep. It's
already hard enough to get Web authors to use ARIA correctly when the
syntax is not overloaded with other concerns. I think ARIA doesn't
need to be strictly restricted to communicating with assistive
technologies that are logically separate from the browser itself--I
think it's OK to implement e.g. "go to [landmark]" functionality by
other means also, such as keyboard shortcuts or visual browser chrome.

Henri Sivonen
Received on Tuesday, 12 May 2015 11:35:29 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:46:13 UTC