- From: Doug Schepers <schepers@w3.org>
- Date: Fri, 31 Oct 2008 19:47:33 -0400
- To: public-svg-wg@w3.org
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