RE: Is ARIA A11y only? [Was: @aria-describedat at-risk ...]

James Craig wrote:
>
> >
> > I'm open to proposals as to how best to do this, and I will take some
> > time to see if I have notions on how to do it.
> >
> > Perhaps some additional language were we discuss our reliance on
> > RFC2119 would help. But, let's do what we must to make it very clear.
> >
> > James, would this kind of clarification work for you?
>
> I see no ambiguity in the statement above, and cannot think of any
> acceptable re-wording that would allow for an RFC-2119 SHOULD.
>
> If you want to change these statements from SHOULD to MAY, that would
> suffice, as it would effectively make them no longer requirements.
> MAY/OPTIONAL recommendations are in line in the prose above. UI
> requirements including "UAs SHOULD" are not.

James,

I've already raised this previously, but to date you've not responded.

I am quite concerned that you are conflating GUI with UI, and User Agent
with Browser, and in both cases I believe that is part of the sticking
point.

Anything that exposes a link to a User Agent "that directly supports ARIA"
(and more precisely this aria attribute) MUST (never mind should) provide a
trigger mechanism to activate that link, and the triggering of that link
MUST be device independent to be fully accessible. (HTML5 reference:
http://www.w3.org/TR/html5/dom.html#interactive-content)
If you are arguing to the contrary, then we have a bigger discussion on our
hands.

There are multiple "user agents" out there above-and-beyond "browsers", and
I see absolutely nothing in the draft text that suggests "browsers" have to
make changes to their GUI - or I think more importantly to the author's GUI
design (I personally don't think this precludes GUI-based user-agents from
making changes to their chrome - and they do that all the time already, as
new features are added. Firefox just rolled out Hello Firefox, and added a
new button to the chrome this week. Both Firefox and Chrome expose @longdesc
in the context menu, which most would consider an extension of the browser
chrome, and not the authors GUI design). While I do not claim to speak for
all, I believe that many are in accordance with this view already.

Since the only way to activate the link referenced by the attribute is via a
trigger mechanism, the text says that the trigger must be activation-device
agnostic. Reading any other requirement into that text is simply, in my
opinion, reading more into the text than is there.


I have also previously stated that your assertion that ARIA is not supposed
to change the UI is incorrect. ARIA currently changes the aural UI all the
time, and I have previously pointed to role="presentation" when applied to
<table> - the semantics and user interface/user experience/user-interaction
for non-sighted users are all drastically altered when this aria attribute
is supported. It makes no changes to the GUI, but huge changes to what is
communicated to the AAPIs, and to the end UI for some users. There is a
significant difference between GUI and UI, and in this discussion (or any
discussion regarding ARIA) I believe it is important to note and remember
those differences.

Finally, lest there be any confusion, I agree with your assertions that ARIA
should not make changes to the authors GUI (unless of course the end user
invokes those changes), and if it makes it any easier, I for one would fully
support adding normative text to that effect in the spec. But focusing on
"device-independent" in the current draft is not the way to solve the issue
(IMHO).

JF

Received on Thursday, 11 December 2014 23:45:21 UTC