Re-land: Create AXAction and AXActionData as a way to simplify accessibility actions

Re-land: Create AXAction and AXActionData as a way to simplify accessibility actions

Original review: https://codereview.chromium.org/2410333005/
Landed in r425980, reverted in r425984 due to a conflict that landed
after the try runs finished but before this change was committed.

Previously we had a collection of 10 accessibility actions that were
implemented on every accessibility object - all of them implemented for
the web, and about half implemented for aura views and for the automation
extension API.

This resulted in a lot of boilerplate code because of the many layers of
indirection between the various parts of the codebase. Adding a new
accessibility action meant adding a new IPC and adding a new method to around
a dozen files just to plumb it through.

In comparison, we have dozens of accessibility events but we handle them all
with a single flexible data structure, so adding a new event doesn't require
so much plumbing.

This change streamlines accessibility actions too. There's
an enum AXAction with all of the possible accessibility actions, and a
serializable data structure AXActionData that encapsulates the parameters
needed by an accessibility action.

This cuts down on some duplicate code and reduces the amount of new code
that needs to be written to add support for a new accessibility action in
the future. For example, macOS has "increment" and "decrement" actions for
range controls that we ought to support, and there are some additional
arguments to setAccessibilityFocus that we're contemplating.

BUG=655272, 655273
TESTED=Manually triggered each of the supported accessibility actions from
    ChromeVox, and from at least one native screen reader.
TBR=dtseng@chromium.org,tsepez@chromium.org,jam@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Committed: https://crrev.com/e6f29fcd6e289b6724b8812cf2be8b1c74774fa2
Cr-Commit-Position: refs/heads/master@{#426221}

[dmazzoni, 2016-10-18 22:49:58]

Description was changed from

==========
Re-land: Create AXAction and AXActionData as a way to simplify accessibility
actions

Original review: https://codereview.chromium.org/2410333005/
Landed in r425980, reverted in r425984 due to a conflict that landed
after the try runs finished but before this change was committed.

Previously we had a collection of 10 accessibility actions that were
implemented on every accessibility object - all of them implemented for
the web, and about half implemented for aura views and for the automation
extension API.

This resulted in a lot of boilerplate code because of the many layers of
indirection between the various parts of the codebase. Adding a new
accessibility action meant adding a new IPC and adding a new method to around
a dozen files just to plumb it through.

In comparison, we have dozens of accessibility events but we handle them all
with a single flexible data structure, so adding a new event doesn't require
so much plumbing.

This change streamlines accessibility actions too. There's
an enum AXAction with all of the possible accessibility actions, and a
serializable data structure AXActionData that encapsulates the parameters
needed by an accessibility action.

This cuts down on some duplicate code and reduces the amount of new code
that needs to be written to add support for a new accessibility action in
the future. For example, macOS has "increment" and "decrement" actions for
range controls that we ought to support, and there are some additional
arguments to setAccessibilityFocus that we're contemplating.

BUG=655272, 655273
TESTED=Manually triggered each of the supported accessibility actions from
    ChromeVox, and from at least one native screen reader.
TBR=dtseng@chromium.org,tsepez@chromium.org,jam@chromium.org
==========

to

==========
Re-land: Create AXAction and AXActionData as a way to simplify accessibility
actions

Original review: https://codereview.chromium.org/2410333005/
Landed in r425980, reverted in r425984 due to a conflict that landed
after the try runs finished but before this change was committed.

Previously we had a collection of 10 accessibility actions that were
implemented on every accessibility object - all of them implemented for
the web, and about half implemented for aura views and for the automation
extension API.

This resulted in a lot of boilerplate code because of the many layers of
indirection between the various parts of the codebase. Adding a new
accessibility action meant adding a new IPC and adding a new method to around
a dozen files just to plumb it through.

In comparison, we have dozens of accessibility events but we handle them all
with a single flexible data structure, so adding a new event doesn't require
so much plumbing.

This change streamlines accessibility actions too. There's
an enum AXAction with all of the possible accessibility actions, and a
serializable data structure AXActionData that encapsulates the parameters
needed by an accessibility action.

This cuts down on some duplicate code and reduces the amount of new code
that needs to be written to add support for a new accessibility action in
the future. For example, macOS has "increment" and "decrement" actions for
range controls that we ought to support, and there are some additional
arguments to setAccessibilityFocus that we're contemplating.

BUG=655272, 655273
TESTED=Manually triggered each of the supported accessibility actions from
    ChromeVox, and from at least one native screen reader.
TBR=dtseng@chromium.org,tsepez@chromium.org,jam@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

[dmazzoni, 2016-10-18 22:52:08]

The CQ bit was checked by dmazzoni@chromium.org

[commit-bot: I haz the power, 2016-10-18 22:52:32]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-19 00:18:24]

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

[commit-bot: I haz the power, 2016-10-19 00:18:25]

Try jobs failed on following builders:
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[dmazzoni, 2016-10-19 05:01:34]

The CQ bit was checked by dmazzoni@chromium.org

[commit-bot: I haz the power, 2016-10-19 05:03:51]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-19 09:59:45]

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

[commit-bot: I haz the power, 2016-10-19 09:59:48]

Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[dmazzoni, 2016-10-19 15:34:10]

The CQ bit was checked by dmazzoni@chromium.org

[commit-bot: I haz the power, 2016-10-19 15:35:00]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-19 16:35:07]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-10-21 13:09:21]

Description was changed from

==========
Re-land: Create AXAction and AXActionData as a way to simplify accessibility
actions

Original review: https://codereview.chromium.org/2410333005/
Landed in r425980, reverted in r425984 due to a conflict that landed
after the try runs finished but before this change was committed.

Previously we had a collection of 10 accessibility actions that were
implemented on every accessibility object - all of them implemented for
the web, and about half implemented for aura views and for the automation
extension API.

This resulted in a lot of boilerplate code because of the many layers of
indirection between the various parts of the codebase. Adding a new
accessibility action meant adding a new IPC and adding a new method to around
a dozen files just to plumb it through.

In comparison, we have dozens of accessibility events but we handle them all
with a single flexible data structure, so adding a new event doesn't require
so much plumbing.

This change streamlines accessibility actions too. There's
an enum AXAction with all of the possible accessibility actions, and a
serializable data structure AXActionData that encapsulates the parameters
needed by an accessibility action.

This cuts down on some duplicate code and reduces the amount of new code
that needs to be written to add support for a new accessibility action in
the future. For example, macOS has "increment" and "decrement" actions for
range controls that we ought to support, and there are some additional
arguments to setAccessibilityFocus that we're contemplating.

BUG=655272, 655273
TESTED=Manually triggered each of the supported accessibility actions from
    ChromeVox, and from at least one native screen reader.
TBR=dtseng@chromium.org,tsepez@chromium.org,jam@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

to

==========
Re-land: Create AXAction and AXActionData as a way to simplify accessibility
actions

Original review: https://codereview.chromium.org/2410333005/
Landed in r425980, reverted in r425984 due to a conflict that landed
after the try runs finished but before this change was committed.

Previously we had a collection of 10 accessibility actions that were
implemented on every accessibility object - all of them implemented for
the web, and about half implemented for aura views and for the automation
extension API.

This resulted in a lot of boilerplate code because of the many layers of
indirection between the various parts of the codebase. Adding a new
accessibility action meant adding a new IPC and adding a new method to around
a dozen files just to plumb it through.

In comparison, we have dozens of accessibility events but we handle them all
with a single flexible data structure, so adding a new event doesn't require
so much plumbing.

This change streamlines accessibility actions too. There's
an enum AXAction with all of the possible accessibility actions, and a
serializable data structure AXActionData that encapsulates the parameters
needed by an accessibility action.

This cuts down on some duplicate code and reduces the amount of new code
that needs to be written to add support for a new accessibility action in
the future. For example, macOS has "increment" and "decrement" actions for
range controls that we ought to support, and there are some additional
arguments to setAccessibilityFocus that we're contemplating.

BUG=655272, 655273
TESTED=Manually triggered each of the supported accessibility actions from
    ChromeVox, and from at least one native screen reader.
TBR=dtseng@chromium.org,tsepez@chromium.org,jam@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Committed: https://crrev.com/e6f29fcd6e289b6724b8812cf2be8b1c74774fa2
Cr-Commit-Position: refs/heads/master@{#426221}
==========

[commit-bot: I haz the power, 2016-10-21 13:09:23]

Patchset 2 (id:??) landed as
https://crrev.com/e6f29fcd6e289b6724b8812cf2be8b1c74774fa2
Cr-Commit-Position: refs/heads/master@{#426221}