Adding DumpAccessibilityTree Tests (8 of 20)

Adding DumpAccessibilityTree Tests (8 of 20)

HTML Tags: object, ins, mark, i, legend, frameset, caption, body, th
Aria role: row, spinbutton
Aria state/property: aria-atomic

BUG=170580
Committed: https://crrev.com/711d923e3b9dd778e482f991f280e6dd937d1abf
Cr-Commit-Position: refs/heads/master@{#294739}

[shreeramk, 2014-09-05 13:34:03]

shreeram.k@samsung.com changed reviewers:
+ dmazzoni@chromium.org

[shreeramk, 2014-09-05 13:34:04]

PTAL!

[shreeramk, 2014-09-05 13:37:08]

Not sure why for object AXUnknown is coming.

https://codereview.chromium.org/543953003/diff/20001/content/test/data/access...
File content/test/data/accessibility/frameset-expected-mac.txt (right):

https://codereview.chromium.org/543953003/diff/20001/content/test/data/access...
content/test/data/accessibility/frameset-expected-mac.txt:2: AXUnknown
I think this is AXUnknown because Spec says frameset 'Not Mapped'

[dmazzoni, 2014-09-08 05:10:27]

Thanks *very much* for these.

Note that DumpAccessibilityTree only dumps some of the most common attributes by
default. However, many of these tests are specifically testing for relatively
obscure attributes. You'll need to use an ALLOW line to make sure those show up
in the results.

My suggestion is to put @MAC-ALLOW:* and @WIN-ALLOW:* at the top, run it through
try jobs, then try to cut down the ALLOW lines to only allow what's actually
relevant to each test.

Also, please refer to the official spec:

http://www.w3.org/TR/wai-aria-implementation/
http://www.w3.org/TR/html-aapi/

For each element or attribute or role, check the spec. If the spec says that the
output role should be one thing on Windows or that it should have a certain
state or attribute and you're seeing it's something else, don't check in the
test! Either mark it as SKIP with a note, or don't add it - checking in the test
without matching the spec would confuse us into thinking it's working correctly
when it's not.

https://codereview.chromium.org/543953003/diff/60001/content/test/data/access...
File content/test/data/accessibility/aria-atomic-expected-mac.txt (right):

https://codereview.chromium.org/543953003/diff/60001/content/test/data/access...
content/test/data/accessibility/aria-atomic-expected-mac.txt:3: AXStaticText
AXValue='This test is for aria-atomic="false"'
I expect AXARIAAtomic here (see comment in win file)

https://codereview.chromium.org/543953003/diff/60001/content/test/data/access...
File content/test/data/accessibility/aria-atomic-expected-win.txt (right):

https://codereview.chromium.org/543953003/diff/60001/content/test/data/access...
content/test/data/accessibility/aria-atomic-expected-win.txt:2:
IA2_ROLE_PARAGRAPH name='This test is for aria-atomic="false"' FOCUSABLE
The aria-atomic should be reported here. There are a lot of less common
attributes that are hidden by default. Try adding: @WIN-ALLOW:* and run it again
and you'll see the results. Then change the @WIN-ALLOW to something more
restricted that only dumps the relevant attributes.

https://codereview.chromium.org/543953003/diff/60001/content/test/data/access...
File content/test/data/accessibility/aria-atomic.html (right):

https://codereview.chromium.org/543953003/diff/60001/content/test/data/access...
content/test/data/accessibility/aria-atomic.html:4: <p id="ariaatomic"
aria-atomic="false" tabindex="0"> This test is for aria-atomic="false" </p>
aria-atomic is only defined for live regions, so to make this a valid example it
should also have either aria-live="polite" or a role like role="log" or
role="timer".

https://codereview.chromium.org/543953003/diff/60001/content/test/data/access...
File content/test/data/accessibility/aria-row.html (right):

https://codereview.chromium.org/543953003/diff/60001/content/test/data/access...
content/test/data/accessibility/aria-row.html:6: <tr role="row">
This isn't a good example because <tr> already has an implicit role of "row".
Make a full ARIA table for this to be more interesting.

https://codereview.chromium.org/543953003/diff/60001/content/test/data/access...
File content/test/data/accessibility/aria-spinbutton-expected-mac.txt (right):

https://codereview.chromium.org/543953003/diff/60001/content/test/data/access...
content/test/data/accessibility/aria-spinbutton-expected-mac.txt:2: AXSlider
AXValue='50'
This should have an orientation of vertical and I believe it has a role
description. Use an ALLOW to make sure those show

[shreeramk, 2014-09-09 11:30:44]

For aria-row I ll take care in the next patch set.

In this patch set I have uploaded correct win expectations and added @MAC-ALLOW
to get the attributes properly.

Also, I have removed aria-spinbutton.html, because this test case is already
present as spinbutton.html.

[shreeramk, 2014-09-09 14:25:32]

On 2014/09/09 11:30:44, shreeram.k wrote:
> For aria-row I ll take care in the next patch set.
> 
> In this patch set I have uploaded correct win expectations and added
@MAC-ALLOW
> to get the attributes properly.
> 
> Also, I have removed aria-spinbutton.html, because this test case is already
> present as spinbutton.html.

Even after adding @MAC-ALLOW:*, still for frameset and object.html , the same
AXUnknown output is coming in expectation.

And aria-atomic.html, for windows I added the expectation file by generating on
windows. But for Mac the try bots are still giving wrong output.

[dmazzoni, 2014-09-09 21:28:20]

On 2014/09/09 14:25:32, shreeram.k wrote:
> On 2014/09/09 11:30:44, shreeram.k wrote:
> > For aria-row I ll take care in the next patch set.
> > 
> > In this patch set I have uploaded correct win expectations and added
> @MAC-ALLOW
> > to get the attributes properly.
> > 
> > Also, I have removed aria-spinbutton.html, because this test case is already
> > present as spinbutton.html.
> 
> Even after adding @MAC-ALLOW:*, still for frameset and object.html , the same
> AXUnknown output is coming in expectation.

I'm okay with that, go ahead and remove the ALLOW:* and check those in as-is.
I'll fix them to map to something more useful later, but for now the elements
that are getting AXUnknown aren't important ones.

> And aria-atomic.html, for windows I added the expectation file by generating
on
> windows. But for Mac the try bots are still giving wrong output.

I think you missed this comment I made earlier:

On 2014/09/08 05:10:27, dmazzoni wrote:
> aria-atomic is only defined for live regions, so to make this a valid example
it
> should also have either aria-live="polite" or a role like role="log" or
> role="timer".

AXARIAAtomic isn't being returned because it's not inside of a live region.

[dmazzoni, 2014-09-09 21:28:41]

https://codereview.chromium.org/543953003/diff/120001/content/test/data/acces...
File content/test/data/accessibility/aria-atomic-expected-win.txt (right):

https://codereview.chromium.org/543953003/diff/120001/content/test/data/acces...
content/test/data/accessibility/aria-atomic-expected-win.txt:4:
ROLE_SYSTEM_CLIENT FOCUSABLE atomic:true container-atomic:true
Thanks, this looks perfect

[shreeramk, 2014-09-10 11:46:36]

I added expectations file aria-row.html for windows.

On Android its giving TIMEOUT. And hence getting failed.(Skipping this also for
the time being)


Reason for MAC Failure:

ASSERTION FAILED: child->isTableCell()
../../third_party/WebKit/Source/core/accessibility/AXTable.cpp(514) :
blink::AXTableCell *blink::AXTable::cellForColumnAndRow(unsigned int, unsigned
int)

I raised a bug http://code.google.com/p/chromium/issues/detail?id=412735 and I
ll add skip in the expectation file and upload it.

[shreeramk, 2014-09-10 16:19:07]

On 2014/09/10 11:46:36, shreeram.k wrote:
> I added expectations file aria-row.html for windows.
> 
> On Android its giving TIMEOUT. And hence getting failed.(Skipping this also
for
> the time being)
> 
> 
> Reason for MAC Failure:
> 
> ASSERTION FAILED: child->isTableCell()
> ../../third_party/WebKit/Source/core/accessibility/AXTable.cpp(514) :
> blink::AXTableCell *blink::AXTable::cellForColumnAndRow(unsigned int, unsigned
> int)
> 
> I raised a bug http://code.google.com/p/chromium/issues/detail?id=412735 and I
> ll add skip in the expectation file and upload it.

I think I know why the ASSERTION Fail is coming on MAC, may be because of a
small mistake in aria-row.html file. Last <span> tag has wrong spelling of role.

Because of similar reason I think its failing on windows also.

Sorry for this :( . I ll update and upload the patch.

[shreeramk, 2014-09-11 06:38:17]

PTAL!
Now all done!

[dmazzoni, 2014-09-11 17:02:38]

Just a few more quick things then this should be ready. Thanks!

https://codereview.chromium.org/543953003/diff/200001/content/test/data/acces...
File content/test/data/accessibility/ins-expected-android.txt (right):

https://codereview.chromium.org/543953003/diff/200001/content/test/data/acces...
content/test/data/accessibility/ins-expected-android.txt:2: android.view.View
clickable name='My favorite browser isABCChrome!'
This is a bug that the Android text runs together like this. The name should be
'My favorite browser is ABC Chrome!', right? What you should do in this case is
make the expected-android.txt file look the way it SHOULD be, not the way it
actually is - then add a SKIP line to the top of the file, and file a new bug
for it.

This saves a lot of work for whoever fixes the bug - they have a test that shows
them exactly what happens now, what should happen, and they just have to delete
the "skip" line when they fix it.

https://codereview.chromium.org/543953003/diff/200001/content/test/data/acces...
File content/test/data/accessibility/legend-expected-mac.txt (right):

https://codereview.chromium.org/543953003/diff/200001/content/test/data/acces...
content/test/data/accessibility/legend-expected-mac.txt:2: AXGroup
This element should have an AXTitleUIElement attribute pointing to the <legend>
element, it should be similar to this one:
content/test/data/accessibility/aria-labelledby-heading-expected-mac.txt

https://codereview.chromium.org/543953003/diff/200001/content/test/data/acces...
File content/test/data/accessibility/mark-expected-android.txt (right):

https://codereview.chromium.org/543953003/diff/200001/content/test/data/acces...
content/test/data/accessibility/mark-expected-android.txt:2: android.view.View
clickable name='This test is to checkmark tag.'
Same here - there should be a space between "check" and "mark", so file a bug
for this

https://codereview.chromium.org/543953003/diff/200001/content/test/data/acces...
File content/test/data/accessibility/th.html (right):

https://codereview.chromium.org/543953003/diff/200001/content/test/data/acces...
content/test/data/accessibility/th.html:5: <table>
This test isn't really doing what you want because there are heuristics to try
to detect really trivial tables and present them as plain text rather than
tables. To override that you can give the table a border: add style="border: 1px
solid #000;" to the table element, for example. Then you should see table and
cell roles in the 

Alternatively, I think we may already have one or two other tests that cover
tables? If so, just make sure there's a TH element in these and then we don't
need this separate test.

[shreeramk, 2014-09-11 19:27:05]

On 2014/09/11 17:02:38, dmazzoni wrote:

>
https://codereview.chromium.org/543953003/diff/200001/content/test/data/acces...
> File content/test/data/accessibility/legend-expected-mac.txt (right):
> 
>
https://codereview.chromium.org/543953003/diff/200001/content/test/data/acces...
> content/test/data/accessibility/legend-expected-mac.txt:2: AXGroup
> This element should have an AXTitleUIElement attribute pointing to the
<legend>
> element, it should be similar to this one:
> content/test/data/accessibility/aria-labelledby-heading-expected-mac.txt

I have one doubt. 

legend is a html tag. And spec says for MAC, it can have following accessibility
attributes:

AXRole: AXGroup
AXSubrole: (nil)
AXRoleDescription: group

Then how it can have AXTitleUIElement attribute pointing to it? Or all the
attributes are not mentioned in the spec??

I checked on the try bot server(in following revision NOT FOR REVIEW
https://codereview.chromium.org/552133005/#ps20001), its having AXTitleUIElement
attribute on adding @MAC-ALLOW:* 

How come???

[dmazzoni, 2014-09-11 19:40:34]

On Thu, Sep 11, 2014 at 12:27 PM, <shreeram.k@samsung.com> wrote:

> legend is a html tag. And spec says for MAC, it can have following
> accessibility
> attributes:
>
> AXRole: AXGroup
> AXSubrole: (nil)
> AXRoleDescription: group
>
> Then how it can have AXTitleUIElement attribute pointing to it? Or all the
> attributes are not mentioned in the spec??
>

To clarify, the AXTitleUIElement attribute should be on the fieldset, and
it should point to the legend.

In this case, the spec is incomplete / wrong. Note that it specifies the
relation between the legend and fieldset on Windows, though.


>
> I checked on the try bot server(in following revision NOT FOR REVIEW
> https://codereview.chromium.org/552133005/#ps20001), its having
> AXTitleUIElement
> attribute on adding @MAC-ALLOW:*
>
> How come???
>
> https://codereview.chromium.org/543953003/
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to chromium-reviews+unsubscribe@chromium.org.
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[shreeramk, 2014-09-12 17:24:50]

PTAL!


1. Bug filed for mark.html and ins.html related to space - crbug.com/413531

2. Added <th> tag in table-simple.html

3. legend.html is updated.

[dmazzoni, 2014-09-12 17:33:48]

The CQ bit was checked by dmazzoni@chromium.org

[dmazzoni, 2014-09-12 17:33:49]

lgtm

Great, thanks!

[commit-bot: I haz the power, 2014-09-12 17:34:29]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patchset/543953003/240001

[commit-bot: I haz the power, 2014-09-12 17:52:51]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-09-12 17:52:52]

Try jobs failed on following builders:
  android_clang_dbg_recipe on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_clang_d...)
  mac_chromium_compile_dbg on tryserver.chromium.mac
(http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  win_chromium_compile_dbg on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)

[shreeramk, 2014-09-13 06:32:36]

The CQ bit was checked by shreeram.k@samsung.com

[commit-bot: I haz the power, 2014-09-13 06:33:05]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patchset/543953003/240001

[commit-bot: I haz the power, 2014-09-13 07:18:05]

Committed patchset #13 (id:240001) as da5ef67d8cdb8ed79facef901d7882631b8bb677

[commit-bot: I haz the power, 2014-09-13 07:21:54]

Patchset 13 (id:??) landed as
https://crrev.com/711d923e3b9dd778e482f991f280e6dd937d1abf
Cr-Commit-Position: refs/heads/master@{#294739}

[jam, 2014-09-14 06:20:37]

On 2014/09/13 07:21:54, I haz the power (commit-bot) wrote:
> Patchset 13 (id:??) landed as
> https://crrev.com/711d923e3b9dd778e482f991f280e6dd937d1abf
> Cr-Commit-Position: refs/heads/master@{#294739}

btw i reverted this. some examples of flaky failures 
http://build.chromium.org/p/chromium.mac/builders/Mac10.6%20Tests%20%281%29/b...
http://build.chromium.org/p/chromium.mac/builders/Mac10.7%20Tests%20%281%29/b...
http://build.chromium.org/p/chromium.win/builders/Win7%20Tests%20%28dbg%29%28...
http://build.chromium.org/p/chromium.win/builders/Win7%20Tests%20%281%29/buil...