Re: role="contexthelp"

Hi, Cameron-

As discussed during the telcon and our chat (transcript included below),
I am sympathetic to your point, and agree that we should avoid assigning
behaviors to role values, despite the benefit of authorial incentive,
until there is a clear mechanism for exposing to the author the
knowledge of UA behavior (and thus whether or not they need to provide
an explicit script mechanism to compensate).  I have removed the
"contexthelp" role, and indicated that we may include a way to toggle
tooltips explicitly in a future version of the spec.  Please let us know
if this satisfies your comment.

Thanks-
-Doug

Cameron McCormack wrote (on 10/21/08 7:38 AM):
> Hello WG.
> 
> In the description of the @role attribute in the Structure chapter it
> currently says:
> 
>   Unlike the 'class' attribute, 'role' attribute values are intended to
>   be selected from a predefined set of values with specific semantic
>   aspects that are assigned to the element, such as those defined in the
>   ARIA ontology, XHTML Role Attribute Module, XHTML Vocabulary
>   collection, and in future SVG specifications.
>    — http://dev.w3.org/SVG/profiles/1.2T/publish/struct.html#RoleAttribute
> 
> It then goes on to describe a "contexthelp" role.  It looks like this is
> being defined by SVG Tiny 1.2.  (I couldn’t find it in the ARIA ontology
> or XHTML Vocabulary collection.)  Is this the only role SVG Tiny 1.2
> defines?  Perhaps the quoted paragraph above should also mention that
> the attribute is also intended to use role values defines in this
> specification.
> 
> I’m not clear on why "contexthelp" is defined here rather than
> recommending the use of ARIA’s "tooltip" role.  Is there a distinction
> that I’m missing?
> 
> How do you associate the context help element with the element that it
> is the context help for?  For example, with ARIA's "tooltip" you would
> use an @aria-describedby attribute on the element that is being
> described by the element with role="tooltip".  There doesn’t seem to be
> an equivalent attribute for use with "contexthelp".  IIUC I think I’d
> need to be able to do something like the following:
> 
>   <svg …>
>     <g id='Window1' transform='…'>
>       …
>       <g id='Button1' describedby='ContextHelp'>
>         …
>       </g>
>     </g>
>     <g id='ContextHelp' transform='…' role='contexthelp'>
>       <rect width='200' height='20' rx='5' fill='yellow'/>
>       <image xlink:href='info-balloon.png'
>              x='5' width='20' height='20'/>
>       <text x='30' y='15' font-size='10'>
>         Click this button if you rock!
>       </text>
>     </g>
>   </svg>
> 
> I find it a little odd that the "contexthelp" role is defined here not
> only to inform an AT of the association between an element and some
> graphical content (or textual, if used on a descriptive element) that
> forms a context help popup, but also to cause some particular visual
> processing when used on descriptive elements.  Are roles not meant
> solely for authors to provide hints to ATs on how (in our case)
> graphical content maps to structural UI concepts, such as widgets,
> tooltips and so on?  Should including a role really induce particular
> behaviour in the SVG user agent too?
> 
> I admit I’m a bit of a chobo when it comes to ARIA and roles and so on,
> so if I’m misunderstanding the whole thing please do set me straight.

=============

shepazu: so, how do we move forward?  what is your concrete suggestion?

heycam: well, i think for me the ideal solution would be to remove it so
that it can be discussed further to ensure it's not violating how roles
should work, and replace it with an example of how to use one of the
existing aria roles in svg.
but i understand that you'd rather keep it
since it's a should, it's technically not a problem with regards to
testing, or the fact that no UAs implement this at the moment
but with the should, there's that problem i mentioned yesterday, of some
UAs popping up the contexthelp window and some not
i think this might be one of those situations where the 'should' is
going to be problematic, because authors need to do different things
based on whether the UA adheres to the 'should' or not

shepazu: ok, so there are several problems this is trying to solve
(where "this" is the use of ARIA roles in SVG to trigger UA behavior)
1) the most clear is to provide semantics and AT mapping to SVG content
2) to provide incentive to authors to actually create content that
corresponds to these mappings
3) to allow authors a clean extensible way to toggle popups on and off
maybe I'm overloading role with this

heycam: that's what i feel (that it overloads role), because (1) i
haven't seen publicly that this is the road the accessibility people
want to go down with @role, and (2) it introduces this problem of the
behaviour being implemented or not in a UA

shepazu: one of my concerns is that if we don't get this in a spec soon,
there will be less momentum to do it in the future

heycam: less momentum to have roles with behaviours in general, or less
momentum to have a contexthelp role at all?
or less momentum to use roles in svg?

shepazu: maybe some of this is better dealt with in the context of SVG
2.0 Core, and the SVG Roles module

heycam: right, i'd think that the svg roles module would be a perfect
place to hash it out
when we agreed to add these attributes into 1.2T, it was with the
understanding that they'd be simple just-in-the-DOM attributes
and hence an easy addition at this stage

shepazu: I personally see real value in adding behavior to roles, but I
acknowledge that the transition is problematic (that is, when should the
author provide the behavior, and when to let the UA do it)

heycam: otoh, since 1.2T won't be the core of the language later, it
makes it easier for me to swallow having it in the spec since we can
revisit it to make it right (from my perspective) in the future
do you envisage behaviours being added to the existing ARIA roles?
probably there can't be, since there's going to be some content out
there that assumes there is no behaviour attached
(at a guess)

shepazu: since there is no way of detecting via script what the UA is
doing (another problem), it's not clear how the author would be
guaranteed results
otoh, role is not meant for ARIA alone

heycam: that's true
so there was another technical problem i had
that i mentioned in my mail
http://www.w3.org/mid/20081021113831.GA16336@arc.mcc.id.au
which is the lack of the extra aria attributes that let you specify more
information about the role you're setting
i don't know what the outcome of the whole discussion about these aria
attributes and being prefixed or not was
whether we were going to add @aria-describedby etc.

shepazu: there is an explicit "aria-describedby" relationship with the
title and desc elements

heycam: right, so you don't need to add that attribute in there
since it knows it applies to the parent
with contexthelp i think this isn't always going to be possible
e.g. if the contexthelp applies to a <text> element, you can't place
that content as a child of the <text>

shepazu: well, you can declare it explicitly for external elements, but
'title/desc' can be a child of a <text>

heycam: sure title/desc can, but an arbitrary graphical element (which
draws your contexthelp popup window) can't

shepazu: there's no conflict there
or rather, I don't see the conflict

heycam: so how do i create the graphics for my contexthelp popup window,
and state that it is describing a <text> element?
i think i need @aria-describedby (or @aria:describedby, etc.) to do this

shepazu: what's wrong with the way you have it in your email?

heycam: nothing except for the fact that we don't define the
@describedby attribute, do we?
define/allow

shepazu: not in tiny, but we will add it in the svg roles module

heycam: ok.  so that limits the ability to use roles a bit.
but i suppose there are still some cases when it can be used

shepazu: no, you can use it... it just won't validate
it's not like there's an ARIA validator ready anyway (I don't think
sivonen has finished his)

heycam: ok (but i wouldn't know, as an author, whether i should be using
@aria-describedby, @aria:describedby, @aria_describedby or @describedby)
(since we haven't defined how aria is integrated in svg yet)

shepazu: well, I don't think we know yet, so we can't define it)

heycam: sure

shepazu: so, back to the pressing issue

heycam: ok
in practical terms, if there's something in the spec that turns out to
be wrong or incompatible, and it's a 'should', then it won't get
implemented, but that won't violate conformance

shepazu: I don't like dropping it, for reasons I've stated

heycam: so in that regard, i can be satisfied having it in the spec

shepazu: but I also don't want to slow the spec down, or put more work
into it than we need to, or cause potential conflicts

heycam: i don't want to slow things down either, and i don't want to
conflict
but working to fix the latter will cause a slowdown definitely

shepazu: and we have the existing problem that different UA have
different behaviors wrt title/desc

heycam: and that's really impossible

shepazu: I was hoping to solve that problem in SVG 1.2 Tiny

heycam:  i know you put a lot of effort into the title/desc stuff
i think the reason i overlooked the behaviour association with
title/desc is that because this was specifically on title/desc, which
don't have any rendering, the overloading wasn't too bad
you didn't get that problem like the one with contextrole

shepazu: right now, FF and WebKit don't display titles, Opera and Batik
do, and none of them allows the author to control it or detect when they
would need to provide a script backup
so, do you have a suggestion there?

heycam: for the contextrole behaviour detection problem?

shepazu: no, for title/desc and tooltip

heycam: well, technically i guess you could add a feature string, that
would allow script to know if the UA is going to do something based on
contextrole
oh
no i guess i haven't thought about it enough
without thinking much at all, i'd say that attaching the behaviour to a
different attribute/property rather than @role would be better
i.e. that attribute/property controls whether the UA will render that
title/desc

shepazu: I guess that will have to wait for Core
that's really frustrating

heycam: as i said, i can live with role giving that behaviour for
title/desc a little more easily than the contexthelp thing
what other implementors will think, i'm not sure
i mean i suppose ed_work thinks it's ok or he would've said
and opera is doing aria/role implementation aren't they?
(whereas i'm not, and am not really an expert in that area)

shepazu: honestly, I think it's all part of the same issue... there's
either attached behaviors, or there isn't
(with ARIA)

heycam: yeah i think it is

shepazu: and taking it out basically means that authors are not rewarded
for using ARIA roles

heycam: true, and i think that that's a fundamental issue with aria
roles (since it's a "patch up" technology, rather than providing
specific visual behaviour)
so, let me get back to the practicalities of it

shepazu: ok

heycam: if you believe that defining contexthelp role like this is
architecturally sound with what the aria folks want to do in the future,
and (barring the problem with knowing whether the UA will interpret it
or not), since it's a should i can live with it
but, since i think there are architectural problems with using role like
this, i reckon it won't get implemented

shepazu: or implemented differently

heycam: yeah

shepazu: non-interoperably

heycam: which is something you really wanted to avoid

shepazu: which screws the whole point

heycam: but, having it in the spec now can't make the situation worse, i
think
it'll either make it better, or it'll be ignored and do nothing

shepazu: what about dropping it down to a MAY, to give us more elbow
room in the future?

heycam: i think should = may, in terms of the amount of elbow room it
gives us
though "may" sounds like a weaker exhortation to implement it
and since we've pretty much decided that we can break 1.2T things in the
name of appeasing desktop web browsers in core 2.0...

shepazu: right..
but still
ok, so... what do we do?

heycam: um, i leave it up to you?

shepazu: drop "contexthelp", keep the soft wording for "tooltip",
revisit in Core 2.0 and SVG Roles?

heycam: in my ideal world, where i don't care about anyone else, yes
but, if you want expediency over more confidence in correctness, then we
can go ahead and i won't object

heycam: is my input enough for you to decide what to do?
or have i made you feel more on the fence than before

shepazu: I think I'm going with that... drop "contexthelp", keep the
soft wording for "tooltip", revisit in Core 2.0 and SVG Roles, and
coordinate with WAI to put contexthelp in ARIA

heycam: are you convince by my arguments?

shepazu: that seems the easiest way forward
yes, I think your arguments are sound, and we do need to figure out a
better way for the future, but this is what we can do now

heycam: (i mean obviously i believe i'm right, but don't believe me just
because i'm usually right
ok
sorry that you've put in this effort for title/desc that won't make it
into the spec, but i think it (with some modifications) can go into core

shepazu: ideally, an author could detect when they need to provide
script and when a UA will do some behavior

heycam: yeah
even if the behaviour is a 'must', then authors would want this as a
transition step
when not all UAs implement it

shepazu: wait... let's make sure we're on the same page
what are you expecting me to do with title/desc?

heycam: oh, maybe i misread you
by "keep the soft wording" you mean keep the current wording?
or go back to the softer wording that was there before?

shepazu: well, there was no wording about tooltip before...

heycam: ah
so keeping the role="tooltip"?

shepazu: and making it a suggestion, not a Should

heycam: ok
(again, i think suggestion/should doesn't make much of a difference in
terms of breaking future changes, if we change)

shepazu: I suppose I could be convinced to drop it altogether, but some
of the accessibility people liked it... still, it does creep into the
ARIA-behavior thing

heycam: but i'm still satisfied if that wording is kept in
since i don't think it's as much of a problem as the contexthelp thing

heycam: at least we're mostly on the same page as the the accessibility
people in wanting roles in svg
unlike the forms taskforce people

heycam: so this issue is concluded?

shepazu: if you're satisfied

heycam: i am

shepazu: oki, I guess it is

Received on Friday, 31 October 2008 23:47:43 UTC