Open kbae00 opened 5 years ago
SHOULD is not an absolute requirement, compared to MUST. SHOULD leaves it open for implementations not to do something if there's a good enough reason. so the "typically" phrasing seems to fit that concept. but for avoidance of confusion the latter could probably be swapped with "It should appear..."
APG is non normative so we try to avoid using normative language.
If the normative should in the ARIA spec is actually appropriate, then we could remove the "typically." If there is a reasonable scenario where the delay is not appropriate, we could also add an "unless" phrase that addresses such a scenario. That is our normal approach to "should" in the spec. If it is a "may" in the spec, we would probably just leave it as is.
I wonder, though, if the spec "should" read more like the practices does now? Is normative language justified for that aspect of the description.
I wonder, though, if the spec "should" read more like the practices does now? Is normative language justified for that aspect of the description.
i guess it was put there as a SHOULD to prevent implementations that immediately show tooltips, which would be quite disruptive to users (particularly with cognitive disabilities, I'm hazarding a further guess) as they simply move their mouse over a densely tooltipped bit of content where they'd otherwise constantly get things popping up/covering up the content they're trying to read
Do we know of exceptional circumstances where we would recommend 0 delay? If not, I recommend we resolve this issue by deleting the word "typically."
i wouldn't "outlaw" a 0 delay if the there a very low tooltip density / it's small / doesn't obscure any other content. removing "typically" would make it seem like it's a MUST in ARIA spec, which it isn't...
@patrickhlauke wrote:
i wouldn't "outlaw" a 0 delay if the there a very low tooltip density / it's small / doesn't obscure any other content. removing "typically" would make it seem like it's a MUST in ARIA spec, which it isn't...
If we word it as follows:
A tooltip is a popup that displays information related to an element when the element receives keyboard focus or the mouse hovers over it. It appears after a small delay and disappears when Escape is pressed or on mouse out.
I don't think that outlaws 0 or close to 0 delay. We do not define small. The APG is informative, not normative. It is consistent with how we describe other "author shoulds" where we are not aware of an exception that is common enough to describe.
The rule of thumb has been that if we use the word "typically" that it is best if we can identify the circumstances where atypical behavior is justified. That said, we are not entirely consistent in doing so.
To me, it seems reasonable to go either way -- leav as is or delete typically. We could also entertain an edit that describes atypical.
@kbae00, given the discussion, are you OK closing with no change?
Apologies for the delayed response, I don't use github often and don't have proper email filters set up. Thanks for the responses and clarifications, I feel I have a clear understanding now. I don't know if I can really state my opinion here as this seems to be a matter of language of the APG and Spec themselves and I feel I'd be overstepping my bounds by making language adjustment recommendations. However, it might be helpful to know that my co-workers and I were confused and we read/refer to the spec and APG daily.
I propose the following:
A tooltip is a popup that displays information related to an element when the element receives keyboard focus or the mouse hovers over it. It appears after a brief delay, typically about X milliseconds, and it disappears when Escape is pressed or on mouse out.
I just need a number for X. This would encourage a typical delay but does not imply a very short or 0 delay does not conform with the spec. And, it avoids the challenge of defining a situation that might justify an exception to the typical case.
I think the next best option is likely no change.
Thoughts @kbae00? @patrickhlauke ?
I just need a number for X. This would encourage a typical delay but does not imply a very short or 0 delay does not conform with the spec. And, it avoids the challenge of defining a situation that might justify an exception to the typical case.
Personally, I'd say it's pointless to try and pluck some arbitrary number out of thin air here. If we're claiming something is typical, then we should research this properly and not make things up. But then, I also think there's really no need for a clarification/change, if as you say the spec isn't always consistent about needing to provide a justification/exception. (I mean if pressed, I'd say one exception would be if there's no chance that the tooltip would obscure some other content if there's sufficient margin/padding around the thing with the tooltip).
@patrickhlauke I'm proposing removing the normative should from the spec and replacing with non-normative language there. I don't really see any downsides to that.
ah sorry, missed that (was just trawling through my github emails and didn't follow that reference above to https://github.com/w3c/aria/issues/1035).
yeah, fixing it at that level would work for me as well. assuming then we can leave APG as is, or is there still a need for changes?
No need for APG change - see PR https://github.com/w3c/aria/pull/1037 - would close this too.
ARIA Spec 1.1 and 1.2 for tooltip (role) both say: "authors SHOULD display the tooltip after a short delay". However, the Authoring Practices Guide 1.1 and 1.2 for Tooltip Widget both say "It typically appears after a small delay". The spec makes it sound like the delay is required whereas the APG makes it sound optional. They should be consistent.