Bug 131076
| Summary: | Web Inspector: AXI: Keep heuristic decisions data around to expose. | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Samuel White <samuel_white> |
| Component: | Web Inspector | Assignee: | Aaron Chu <aaron_chu> |
| Status: | NEW | ||
| Severity: | Normal | CC: | graouts, inspector-bugzilla-changes, jcraig, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | 528+ (Nightly build) | ||
| Hardware: | Mac (Intel) | ||
| OS: | OS X 10.9 | ||
Samuel White
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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/16493057>
James Craig
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.
James Craig
Seems like Chrome DevTools are shipping item #3.
https://www.youtube.com/watch?v=B9qzdVcIj5U (~15:45)