Currently AXLayoutObject computes the role by looking at the type of the LayoutObject - so that's how it knows a progress bar, for example. But that will fail when the progress bar has --webkit-appearance: none.

AXNodeObject also has some role computation code. Not sure if it works in the progress bar case, but it should - and it should be based only on the element tag and attributes, not on the layout.

I think that if AXLayoutObject fails to assign a non-default role, AXNodeObject should get a chance to assign a role. That ought to fix this bug.

I think this is possibly a good first bug.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9f0388a6f32a6ed295549043735181c8f021fa0c

commit 9f0388a6f32a6ed295549043735181c8f021fa0c
Author: Rob Dodson <robdodson@chromium.org>
Date: Mon Jan 22 22:52:06 2018

Progress elements with -webkit-appearance: none should retain their role.

If a <progress> element has its appearance removed with -webkit-appearance:none,
it should still retain its role for accessibility. This CL also adds a test
to check that various other control types are not affected by this issue.

R=aboxhall@chromium.org

Bug:  687828 
Change-Id: I1a30e581dd109b34cae69ec9737cb233ceb5f1fb
Reviewed-on: https://chromium-review.googlesource.com/861054
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Commit-Queue: Rob Dodson <robdodson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#531034}
[add] https://crrev.com/9f0388a6f32a6ed295549043735181c8f021fa0c/third_party/WebKit/LayoutTests/accessibility/appearance-affects-role.html
[modify] https://crrev.com/9f0388a6f32a6ed295549043735181c8f021fa0c/third_party/WebKit/Source/modules/accessibility/AXLayoutObject.cpp
[modify] https://crrev.com/9f0388a6f32a6ed295549043735181c8f021fa0c/third_party/WebKit/Source/modules/accessibility/AXNodeObject.cpp