Changed accessibility properies to meet W3C standard.

Changed accessibility properies to meet W3C standard.

Added missing stringValue implementation for slider and menu list elements.
Fixed role property for menu list to correct value.

Patch fixes failing canvas-fallback-content-2 test.

BUG=385014

[m.lapinski, 2015-01-29 12:55:38]

m.lapinski@samsung.com changed reviewers:
+ dmazzoni@chromium.org

[dmazzoni, 2015-01-29 16:28:29]

I suspect this will change the output of some DumpAccessibilityTree tests on the
Chromium side.

Before landing this change, you'll need to either run content_browsertests and
see what fails, or submit a try job. Then disable the tests first, land this
change, and then update the tests.

https://codereview.chromium.org/887643003/diff/1/Source/modules/accessibility...
File Source/modules/accessibility/AXListBox.h (left):

https://codereview.chromium.org/887643003/diff/1/Source/modules/accessibility...
Source/modules/accessibility/AXListBox.h:47: virtual AccessibilityRole
roleValue() const override { return ListBoxRole; }
Did you remove this because it was already handled correctly by AXRenderObject?

https://codereview.chromium.org/887643003/diff/1/Source/modules/accessibility...
File Source/modules/accessibility/AXNodeObject.cpp (right):

https://codereview.chromium.org/887643003/diff/1/Source/modules/accessibility...
Source/modules/accessibility/AXNodeObject.cpp:1205: return input->value();
Thanks, this change looks good.

https://codereview.chromium.org/887643003/diff/1/Source/modules/accessibility...
File Source/modules/accessibility/AXRenderObject.cpp (right):

https://codereview.chromium.org/887643003/diff/1/Source/modules/accessibility...
Source/modules/accessibility/AXRenderObject.cpp:285: return
(selectElement.multiple() || selectElement.size() > 1 ) ? ListBoxRole :
PopUpButtonRole;
I don't think this will return the correct result on all platforms.

On Android, for example, a <select> is a PopUpButton under all of these
circumstances.

That's why it's better for AXRenderObject to check what RenderObject we have,
and as a fallback, AXNodeObject checks what HTML element we have.

[m.lapinski, 2015-01-30 10:46:21]

https://codereview.chromium.org/887643003/diff/1/Source/modules/accessibility...
File Source/modules/accessibility/AXRenderObject.cpp (right):

https://codereview.chromium.org/887643003/diff/1/Source/modules/accessibility...
Source/modules/accessibility/AXRenderObject.cpp:285: return
(selectElement.multiple() || selectElement.size() > 1 ) ? ListBoxRole :
PopUpButtonRole;
On 2015/01/29 16:28:29, dmazzoni wrote:
> I don't think this will return the correct result on all platforms.
> 
> On Android, for example, a <select> is a PopUpButton under all of these
> circumstances.
> 
> That's why it's better for AXRenderObject to check what RenderObject we have,
> and as a fallback, AXNodeObject checks what HTML element we have.

According to standard (working draft)
http://www.w3.org/TR/html-aapi/#el-select-listbox
Accesibility role depends on these conditions so i did it this way. I'll remove
it but it will cause failing canvas-fallback-content-2.html layout test for
android.

[m.lapinski, 2015-02-02 16:24:51]

On 2015/01/29 16:28:29, dmazzoni wrote:
> I suspect this will change the output of some DumpAccessibilityTree tests on
the
> Chromium side.
> 
> Before landing this change, you'll need to either run content_browsertests and
> see what fails, or submit a try job. Then disable the tests first, land this
> change, and then update the tests.
> 

Do you mean test which is described here?
http://www.chromium.org/developers/accessibility/testing
Unfortunately steps from the instructions doesn't work for me.

I've built it by:
$ ninja -C out/Debug browser_tests 

It finished without any problem.
Then I've tried to start tests by following command:

$ out/Debug/content_browsertests --gtest_filter="DumpAccessibilityTree*"

It gave following output:

IMPORTANT DEBUGGING NOTE: each test is run inside its own process.
For debugging a test inside a debugger, use the
--gtest_filter=<your_test_name> flag along with either
--single_process (to run the test in one launcher/browser process) or
--single-process (to do the above, and also run Chrome in single-process mode).
Using sharding settings from environment. This is shard 0/1
Using 1 parallel jobs.
0 tests run

It may be caused by my configuration. I have no rights to launch trybot. Could
you launch it for me?

[m.lapinski, 2015-02-02 16:48:12]

On 2015/02/02 16:24:51, m.lapinski wrote:

> I've built it by:
> $ ninja -C out/Debug browser_tests 
> 
I meant:
ninja -C out/Debug  content_browsertests

[dmazzoni, 2015-02-02 18:59:25]

On 2015/02/02 16:24:51, m.lapinski wrote:
> On 2015/01/29 16:28:29, dmazzoni wrote:
> > I suspect this will change the output of some DumpAccessibilityTree tests on
> the
> > Chromium side.
> > 
> > Before landing this change, you'll need to either run content_browsertests
and
> > see what fails, or submit a try job. Then disable the tests first, land this
> > change, and then update the tests.
> > 
> 
> Do you mean test which is described here?
> http://www.chromium.org/developers/accessibility/testing
> Unfortunately steps from the instructions doesn't work for me.

The tests give different output on each platform, and currently we test Win,
Mac, & Android. You'll need to either build and run on those platforms, or
submit a try job.

Let me look into getting you try job access.

[dmazzoni, 2015-02-02 19:49:25]

https://codereview.chromium.org/887643003/diff/1/Source/modules/accessibility...
File Source/modules/accessibility/AXRenderObject.cpp (right):

https://codereview.chromium.org/887643003/diff/1/Source/modules/accessibility...
Source/modules/accessibility/AXRenderObject.cpp:285: return
(selectElement.multiple() || selectElement.size() > 1 ) ? ListBoxRole :
PopUpButtonRole;
On 2015/01/30 10:46:21, m.lapinski wrote:
> On 2015/01/29 16:28:29, dmazzoni wrote:
> > I don't think this will return the correct result on all platforms.
> > 
> > On Android, for example, a <select> is a PopUpButton under all of these
> > circumstances.
> > 
> > That's why it's better for AXRenderObject to check what RenderObject we
have,
> > and as a fallback, AXNodeObject checks what HTML element we have.
> 
> According to standard (working draft)
> http://www.w3.org/TR/html-aapi/#el-select-listbox
> Accesibility role depends on these conditions so i did it this way. I'll
remove
> it but it will cause failing canvas-fallback-content-2.html layout test for
> android.

Yeah, I think we need to fix the layout test so that it's allowed to have
different output on Android. There's a system for that - the Android-specific
test result goes in a file like:
LayoutTests/platform/android/accessibility/canvas-fallback-2-expected.txt

[m.lapinski, 2015-02-03 13:24:45]

m.lapinski@samsung.com changed reviewers:
+ dmazzoni k.czech@samsung.com
- dmazzoni@chromium.org

[m.lapinski, 2015-02-03 15:05:36]

m.lapinski@samsung.com changed reviewers:
+ dmazzoni@chromium.org
- dmazzoni k.czech@samsung.com

[m.lapinski, 2015-02-18 10:49:30]

I've done what you asked me to. Could you check it out?

[m.lapinski, 2015-02-18 11:01:31]

The CQ bit was checked by m.lapinski@samsung.com

[m.lapinski, 2015-02-18 11:01:31]

The CQ bit was unchecked by m.lapinski@samsung.com

[dmazzoni, 2015-02-18 19:00:28]

Shreeram or Krzysztof, could either of you help by running try jobs and guiding
m.lapinski through this change?

The idea behind the change is fine, but we need to see if any
DumpAccessibilityTree tests need to be temporarily disabled first.

[dmazzoni, 2015-02-18 19:01:38]

https://codereview.chromium.org/887643003/diff/80001/Source/modules/accessibi...
File Source/modules/accessibility/AXRenderObject.cpp (right):

https://codereview.chromium.org/887643003/diff/80001/Source/modules/accessibi...
Source/modules/accessibility/AXRenderObject.cpp:910: if
(isHTMLSelectElement(m_renderer->node())) {
As I commented before, I don't think we should be making this change, I think
using cssBox->isMenuList is correct for AXRenderObject.cpp.

If I'm wrong, please explain why.

[k.czech, 2015-02-18 23:43:56]

On 2015/02/18 19:00:28, dmazzoni wrote:
> Shreeram or Krzysztof, could either of you help by running try jobs and
guiding
> m.lapinski through this change?
> 
> The idea behind the change is fine, but we need to see if any
> DumpAccessibilityTree tests need to be temporarily disabled first.

Sure, I will guide him through this change.

[k.czech, 2015-02-19 23:20:28]

On 2015/02/18 23:43:56, k.czech wrote:
> On 2015/02/18 19:00:28, dmazzoni wrote:
> > Shreeram or Krzysztof, could either of you help by running try jobs and
> guiding
> > m.lapinski through this change?
> > 
> > The idea behind the change is fine, but we need to see if any
> > DumpAccessibilityTree tests need to be temporarily disabled first.
> 
> Sure, I will guide him through this change.

I'm not able to run try-bots for another user. It seems that only committers can
do that.
Every time when I try to run some bots, I get a popup window with a message "An
error occurred while trying to update the issue"

[dmazzoni, 2015-02-20 00:34:27]

On 2015/02/19 23:20:28, k.czech wrote:
> I'm not able to run try-bots for another user. It seems that only committers
can
> do that.
> Every time when I try to run some bots, I get a popup window with a message
"An
> error occurred while trying to update the issue"

I tried to add some try jobs. If that works, great. Another option is for you to
patch this into a new changelist of your own and run try jobs there/

[shreeramk, 2015-03-23 18:06:26]

Developers with special try bot access can run try bot for others in browser on
this(codereview) site.

But if anyone having try job access for him/herself then he/she can run try bots
for others from linux terminal or DOS prompt.

Steps:
1. git checkout -b trybots origin/master
2. git cl issue 887643003
3. git cl patch 887643003
4. git cl try