Bug 131076 - Web Inspector: AXI: Keep heuristic decisions data around to expose.
Summary: Web Inspector: AXI: Keep heuristic decisions data around to expose.
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac (Intel) OS X 10.9
: P2 Normal
Assignee: Aaron Chu
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2014-04-01 16:11 PDT by Samuel White
Modified: 2016-12-13 15:35 PST (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Samuel White 2014-04-01 16:11:40 PDT
Telling developers that AccessibilityTable made a heuristic decision to be a group rather than a table would be very helpful. Although, refactoring the method to include this information would be no easy task. The idea is that if AXTable decides to be a group as a result of our large stack of heuristic checks, we could just include a loc string explaining why. Something like: "presentational table because of missing border."

Also useful when exposing things like "computed label". It would be great if we could tell developers WHY they were seeing what they were seeing. That is, some additional information about how the label got computed. Seems like we could refactor our label computation code to take an additional bool that signals to the machinery that it should keep extra breadcrumb information around to expose (using a bool to avoid doing expensive work during normal computation). Your label comes from XYZ because of aria rule n, etc.
Comment 1 Radar WebKit Bug Importer 2014-04-01 16:11:55 PDT
<rdar://problem/16493057>
Comment 2 James Craig 2014-04-01 16:51:00 PDT
Possibly implement as a series of enum tokens (or even another nest object) that can be attached to the AX Object and passed to the client side as tokens rather than pre-localized strings.

Some aspects that would be useful: 

1. Reasons that lists are determined to be presentational or not. There are a ton of conditionals in AccessibilityTable.cpp. Do we really want to list them out? The UI would be tricky. Determined as group b/c ~"No header row, and no border, and no explicit role, and no caption, and no zebra stripes, and… and… and…" We could potentially just give them the last one triggered. That way they can correct the series by fixing them in sequence.

2. Reasons that lists are determined to be presentational or not. The UI would be tricky, like above: Determined as group b/c ~"No bullets, and no explicit role, (or only one item), and… and… and…"

3. Reasons for result of the computed label algorithm. Sam, since the computedLabel() method doesn't yet exist, this could be our test case or proof-of-concept.
Comment 3 James Craig 2015-10-20 01:11:37 PDT
Seems like Chrome DevTools are shipping item #3. 
https://www.youtube.com/watch?v=B9qzdVcIj5U (~15:45)