WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
169810
AX: Expose a new AXSubrole for explicit ARIA "group" role
https://bugs.webkit.org/show_bug.cgi?id=169810
Summary
AX: Expose a new AXSubrole for explicit ARIA "group" role
James Craig
Reported
2017-03-17 00:59:21 PDT
Currently WebKit exposes no difference between explicit groups (ARIA role="group" and ARIA subroles like doc-biblioentry), generic blocks (<div>, etc), generic inlines that happen to be styled as blocks (<span style=“display:block”), and pseudo-elements (::before).
Attachments
patch
(25.46 KB, patch)
2017-03-17 01:59 PDT
,
James Craig
no flags
Details
Formatted Diff
Diff
patch
(26.20 KB, patch)
2017-03-19 01:39 PDT
,
James Craig
no flags
Details
Formatted Diff
Diff
patch
(26.20 KB, patch)
2017-03-19 01:43 PDT
,
James Craig
no flags
Details
Formatted Diff
Diff
patch
(26.17 KB, patch)
2017-03-20 00:50 PDT
,
James Craig
no flags
Details
Formatted Diff
Diff
patch with Atk mapping
(26.94 KB, patch)
2017-03-20 13:23 PDT
,
James Craig
no flags
Details
Formatted Diff
Diff
Show Obsolete
(4)
View All
Add attachment
proposed patch, testcase, etc.
James Craig
Comment 1
2017-03-17 00:59:41 PDT
<
rdar://problem/31039693
>
James Craig
Comment 2
2017-03-17 01:59:27 PDT
Created
attachment 304768
[details]
patch
James Craig
Comment 3
2017-03-19 01:39:40 PDT
Created
attachment 304894
[details]
patch
James Craig
Comment 4
2017-03-19 01:43:01 PDT
Created
attachment 304895
[details]
patch
James Craig
Comment 5
2017-03-20 00:50:54 PDT
Created
attachment 304917
[details]
patch Updating patch to TOT to potentially fix GTK apply failure.
James Craig
Comment 6
2017-03-20 10:15:11 PDT
Comment on
attachment 304917
[details]
patch Additional info: The fix allows the WebKit Accessibility Inspector to return more accurate role descriptions to distinguish ARIA groups from generic block-level elements in the render tree. (See updated tests.) The fix also provides more differentiation between these groups to each platform accessibility API, providing a way for assistive technologies to convey the differences to the user if desired.
chris fleizach
Comment 7
2017-03-20 11:00:33 PDT
Comment on
attachment 304917
[details]
patch View in context:
https://bugs.webkit.org/attachment.cgi?id=304917&action=review
> Source/WebKit/win/ChangeLog:9 > + Account for Windows platform role mapping.
did you modify GTK files to map this new role
> LayoutTests/accessibility/list-detection2-expected.txt:-20 > -PASS: ul w/ background image (NOT A LIST) -> group.
these objects are no longer groups? that seems unexpected
James Craig
Comment 8
2017-03-20 13:04:37 PDT
Comment on
attachment 304917
[details]
patch View in context:
https://bugs.webkit.org/attachment.cgi?id=304917&action=review
>> Source/WebKit/win/ChangeLog:9 >> + Account for Windows platform role mapping. > > did you modify GTK files to map this new role
Looking into that.
>> LayoutTests/accessibility/list-detection2-expected.txt:-20 >> -PASS: ul w/ background image (NOT A LIST) -> group. > > these objects are no longer groups? that seems unexpected
This is expected. Those elements are still mapped to "AXGroup" (with no subrole) but no longer return "group" as the computed ARIA role string. Layout lists match neither role="list" nor role="group", so web inspector users can now see these have "No exact ARIA role match" rather than the misleading "group" role that previously appeared. I think a future version of ARIA may include a "generic" or some equivalent role for non-semantic container elements like <div> and other elements heuristically determined to be mere layout items. If/when it does, <div>s and layout lists, would vend that role.
James Craig
Comment 9
2017-03-20 13:23:01 PDT
Created
attachment 304945
[details]
patch with Atk mapping
WebKit Commit Bot
Comment 10
2017-03-22 10:14:48 PDT
Comment on
attachment 304945
[details]
patch with Atk mapping Rejecting
attachment 304945
[details]
from commit-queue. Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-02', 'land-attachment', '--force-clean', '--non-interactive', '--parent-command=commit-queue', 304945, '--port=mac']" exit_code: 2 cwd: /Volumes/Data/EWS/WebKit Last 500 characters of output: LayoutTests :040000 040000 5e136b7a9332a5b00b05c6663fb7515d390b1967 7d6fb45c28996bcf8ba5c4bff9fa0a21c5e2ede9 M Source Current branch master is up to date. ERROR: Not all changes have been committed into SVN, however the committed ones (if any) seem to be successfully integrated into the working tree. Please see the above messages for details. Failed to run "['git', 'svn', 'dcommit', '--rmdir']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit Updating OpenSource Current branch master is up to date. Full output:
http://webkit-queues.webkit.org/results/3388201
Joanmarie Diggs
Comment 11
2017-03-30 00:56:00 PDT
Is the plan to re-CQ+ this?
James Craig
Comment 12
2017-03-30 13:32:19 PDT
(In reply to Joanmarie Diggs (irc: joanie) from
comment #11
)
> Is the plan to re-CQ+ this?
Yeah, I filed a WebKit Tools bug in the meantime to diagnose the ambiguous failure, but I'll update to TOT and re-CQ soon.
James Craig
Comment 13
2017-03-30 13:42:21 PDT
Others with the same failure after the site migration.
https://bugs.webkit.org/buglist.cgi?chfieldfrom=3w&chfieldto=Now&list_id=2621140&longdesc=Not%20all%20changes%20have%20been%20committed%20into%20SVN&longdesc_type=allwordssubstr&query_format=advanced
James Craig
Comment 14
2017-03-30 13:43:13 PDT
Comment on
attachment 304945
[details]
patch with Atk mapping First attempting another CQ+ since the failure appears to be transient.
WebKit Commit Bot
Comment 15
2017-03-30 14:13:24 PDT
Comment on
attachment 304945
[details]
patch with Atk mapping Clearing flags on attachment: 304945 Committed
r214623
: <
http://trac.webkit.org/changeset/214623
>
WebKit Commit Bot
Comment 16
2017-03-30 14:13:26 PDT
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug