RESOLVED FIXED Bug 163647
AX: don't expose empty roledescription
https://bugs.webkit.org/show_bug.cgi?id=163647
Summary AX: don't expose empty roledescription
James Craig
Reported 2016-10-18 20:18:45 PDT
ARIA 1.1 include the following restriction on @aria-roledescription > User agents must not expose the aria-roledescription property if … The value of aria-roledescription is empty or contains only whitespace characters. Which seems fine. Please implement. Also note the following restriction in the same section: > User agents must not expose the aria-roledescription property if … The element to which aria-roledescription is applied does not have a valid WAI-ARIA role or does not have an implicit WAI-ARIA role semantic. Which seems overly restrictive and I asked for it to be removed. FWIW, I doubt we'd want to implement this restriction even if the WG declines the spec change. ARIA ISSUE-1048 https://www.w3.org/WAI/ARIA/track/issues/1048
Attachments
Patch (5.43 KB, patch)
2017-05-08 12:00 PDT, Joanmarie Diggs
no flags
Patch (7.57 KB, patch)
2017-05-08 13:08 PDT, Joanmarie Diggs
no flags
Radar WebKit Bug Importer
Comment 1 2016-11-01 17:05:37 PDT
Joanmarie Diggs
Comment 2 2017-05-03 17:19:09 PDT
(In reply to James Craig from comment #0) > Also note the following restriction in the same section: > > User agents must not expose the aria-roledescription property if … The element to which aria-roledescription is applied does not have a valid WAI-ARIA role or does not have an implicit WAI-ARIA role semantic. > > Which seems overly restrictive and I asked for it to be removed. FWIW, I > doubt we'd want to implement this restriction even if the WG declines the > spec change. James: Do you still think it's acceptable to do what you stated in the related github issue [1], namely: <quote> What if you only included this stipulation on generic elements like <div> and <span>? I'd be okay with that restriction. The goal seems to be to avoid problem cases like <div aria-roledescription="button"> and restricting usage on generics would be one way to do that, without penalizing appropriate use on another type of element. </quote> If so, are you ok with my proceeding with that in Safari and WebKitGtk, independent of when the WG adopts the change? [1] https://github.com/w3c/aria/issues/500#issuecomment-266968158
Joanmarie Diggs
Comment 3 2017-05-08 12:00:49 PDT
chris fleizach
Comment 4 2017-05-08 12:04:30 PDT
Comment on attachment 309390 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=309390&action=review > Source/WebCore/accessibility/AccessibilityObject.cpp:2336 > + return !roleDescription.containsOnlyWhitespace() ? roleDescription : String(); should we just trim the whitespace, so that someone putting role=" button" will also work? then you can return the result directly after trimming
Joanmarie Diggs
Comment 5 2017-05-08 13:08:29 PDT
Joanmarie Diggs
Comment 6 2017-05-08 14:07:22 PDT
(In reply to chris fleizach from comment #4) > Comment on attachment 309390 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=309390&action=review > > > Source/WebCore/accessibility/AccessibilityObject.cpp:2336 > > + return !roleDescription.containsOnlyWhitespace() ? roleDescription : String(); > > should we just trim the whitespace, so that someone putting > > role=" button" will also work? > > then you can return the result directly after trimming Done.
WebKit Commit Bot
Comment 7 2017-05-08 15:16:30 PDT
Comment on attachment 309399 [details] Patch Clearing flags on attachment: 309399 Committed r216457: <http://trac.webkit.org/changeset/216457>
WebKit Commit Bot
Comment 8 2017-05-08 15:16:31 PDT
All reviewed patches have been landed. Closing bug.
James Craig
Comment 9 2017-05-17 17:48:25 PDT
(In reply to Joanmarie Diggs (irc: joanie) from comment #2) > James: Do you still think it's acceptable to do what you stated in the > related github issue [1], namely: […snip…] > > If so, are you ok with my proceeding with that in Safari and WebKitGtk, > independent of when the WG adopts the change? Yes, that's fine with me.
Note You need to log in before you can comment on or make changes to this bug.