Support alert nodes by introducing $descendant and !ttsProps.

Support alert nodes by introducing $descendant and !ttsProps.

- ! allowed by a tts property will annotate the output with that property
- $descendants(args...) where args... is a comma delimited list of roles, will compute output for the node's descendants that are in the set of roles.
- apply these two new functions to compute utterances for alerts.

TEST=navigate to a page with an alert like
html5demos.com/geo.
BUG=382650
Committed: https://crrev.com/482aa01deddd1d2e93ebf95b2a0204329c51ae08
Cr-Commit-Position: refs/heads/master@{#314688}

[David Tseng, 2014-12-19 21:41:48]

dtseng@chromium.org changed reviewers:
+ dmazzoni@chromium.org

[dmazzoni, 2014-12-22 08:10:07]

The code looks fine, but I'm not convinced that speaking only static text and
button descendants is what we want to do.

I'm not even convinced that this covers all valid dialogs. What if the dialog
consists of a checkbox, followed by ok / cancel buttons?

But even still, I don't think it degrades gracefully if someone uses ARIA in a
nonstandard but not completely illegal way.

I think I'd rather take the opposite approach - start by having it read the full
contents of the dialog (including roles and all elements), and if that's too
verbose, figure out how to simplify / relax that for some common cases.

[David Tseng, 2014-12-22 16:33:07]

The alert in question (geolocation) is already pretty verbose; what about
focusable controls + static text?

On Mon, Dec 22, 2014 at 12:10 AM, <dmazzoni@chromium.org> wrote:

> The code looks fine, but I'm not convinced that speaking only static text
> and
> button descendants is what we want to do.
>
> I'm not even convinced that this covers all valid dialogs. What if the
> dialog
> consists of a checkbox, followed by ok / cancel buttons?
>
> But even still, I don't think it degrades gracefully if someone uses ARIA
> in a
> nonstandard but not completely illegal way.
>
> I think I'd rather take the opposite approach - start by having it read
> the full
> contents of the dialog (including roles and all elements), and if that's
> too
> verbose, figure out how to simplify / relax that for some common cases.
>
>
> https://codereview.chromium.org/816093002/
>

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

[dmazzoni, 2014-12-22 19:50:27]

What specifically do you *not* want ChromeVox to speak in an alert? What is
there other than controls and text?

On Mon, Dec 22, 2014 at 8:33 AM, David Tseng <dtseng@chromium.org> wrote:
>
> The alert in question (geolocation) is already pretty verbose; what about
> focusable controls + static text?
>
> On Mon, Dec 22, 2014 at 12:10 AM, <dmazzoni@chromium.org> wrote:
>
>> The code looks fine, but I'm not convinced that speaking only static text
>> and
>> button descendants is what we want to do.
>>
>> I'm not even convinced that this covers all valid dialogs. What if the
>> dialog
>> consists of a checkbox, followed by ok / cancel buttons?
>>
>> But even still, I don't think it degrades gracefully if someone uses ARIA
>> in a
>> nonstandard but not completely illegal way.
>>
>> I think I'd rather take the opposite approach - start by having it read
>> the full
>> contents of the dialog (including roles and all elements), and if that's
>> too
>> verbose, figure out how to simplify / relax that for some common cases.
>>
>>
>> https://codereview.chromium.org/816093002/
>>
>
>  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.

[David Tseng, 2014-12-22 19:57:24]

Well, an issue we've seen in the past is reading all of the controls on an
alert; it tends to be very confusing.
For example:
alert, do you want to allow Chrome to use your location? Allow button,
Block button, Close button, Allow button.

The last allow is the focused item. Traditionally, screen readers usually
only read the static text of an alert followed by the focused item to
dramatically cut down on chatter.

This alert also has an image and a link that appear to be nonfocusable and
unlabelled..

On Mon, Dec 22, 2014 at 11:50 AM, Dominic Mazzoni <dmazzoni@chromium.org>
wrote:

> What specifically do you *not* want ChromeVox to speak in an alert? What
> is there other than controls and text?
>
> On Mon, Dec 22, 2014 at 8:33 AM, David Tseng <dtseng@chromium.org> wrote:
>
>> The alert in question (geolocation) is already pretty verbose; what about
>> focusable controls + static text?
>>
>> On Mon, Dec 22, 2014 at 12:10 AM, <dmazzoni@chromium.org> wrote:
>>
>>> The code looks fine, but I'm not convinced that speaking only static
>>> text and
>>> button descendants is what we want to do.
>>>
>>> I'm not even convinced that this covers all valid dialogs. What if the
>>> dialog
>>> consists of a checkbox, followed by ok / cancel buttons?
>>>
>>> But even still, I don't think it degrades gracefully if someone uses
>>> ARIA in a
>>> nonstandard but not completely illegal way.
>>>
>>> I think I'd rather take the opposite approach - start by having it read
>>> the full
>>> contents of the dialog (including roles and all elements), and if that's
>>> too
>>> verbose, figure out how to simplify / relax that for some common cases.
>>>
>>>
>>> https://codereview.chromium.org/816093002/
>>>
>>
>>  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.
>

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

[chromium-reviews, 2014-12-22 20:16:54]

OK, thanks for the explanation. I really want to hold ChromeVox Next to a
high standard and I'm worried about any solution that skips anything just
based on role, because it has the potential to be confusing or incorrect in
an effort to be concise.

I have two thoughts. The first is, how could we make it clear that focus is
on the Allow button? I know it's slightly longer, but how about something
like:

alert, do you want to allow Chrome to use your location? Allow button,
Block button, Close button. [Button earcon] Allow button is focused.

Next, how about if instead of only speaking some roles, how about if we
create a "brief" or "summarize" mode that would (1) cut off static text if
it's too long, and (2) try to group related things together, like this:

alert, do you want to allow Chrome to use your location? 3 buttons. [Button
earcon] Allow button is focused.

Summaries could be something like "Checkbox and 2 buttons" or "Text field
and button", or something like that.

I'd be happy if you wanted to create a skeleton of this summary mode now
and we could improve on it later.

On Mon, Dec 22, 2014 at 11:57 AM, David Tseng <dtseng@chromium.org> wrote:
>
> Well, an issue we've seen in the past is reading all of the controls on an
> alert; it tends to be very confusing.
> For example:
> alert, do you want to allow Chrome to use your location? Allow button,
> Block button, Close button, Allow button.
>
> The last allow is the focused item. Traditionally, screen readers usually
> only read the static text of an alert followed by the focused item to
> dramatically cut down on chatter.
>
> This alert also has an image and a link that appear to be nonfocusable and
> unlabelled..
>
> On Mon, Dec 22, 2014 at 11:50 AM, Dominic Mazzoni <dmazzoni@chromium.org>
> wrote:
>
>> What specifically do you *not* want ChromeVox to speak in an alert? What
>> is there other than controls and text?
>>
>> On Mon, Dec 22, 2014 at 8:33 AM, David Tseng <dtseng@chromium.org> wrote:
>>
>>> The alert in question (geolocation) is already pretty verbose; what
>>> about focusable controls + static text?
>>>
>>> On Mon, Dec 22, 2014 at 12:10 AM, <dmazzoni@chromium.org> wrote:
>>>
>>>> The code looks fine, but I'm not convinced that speaking only static
>>>> text and
>>>> button descendants is what we want to do.
>>>>
>>>> I'm not even convinced that this covers all valid dialogs. What if the
>>>> dialog
>>>> consists of a checkbox, followed by ok / cancel buttons?
>>>>
>>>> But even still, I don't think it degrades gracefully if someone uses
>>>> ARIA in a
>>>> nonstandard but not completely illegal way.
>>>>
>>>> I think I'd rather take the opposite approach - start by having it read
>>>> the full
>>>> contents of the dialog (including roles and all elements), and if
>>>> that's too
>>>> verbose, figure out how to simplify / relax that for some common cases.
>>>>
>>>>
>>>> https://codereview.chromium.org/816093002/
>>>>
>>>
>>>  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.
>>
>
>  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.

[David Tseng, 2015-02-03 22:47:21]

PTAL. Alert announcements are now based upon what a user hears if manually
navigating through the content.

Note that I added nodes of role button as leaf nodes because native views tends
to nest images inside of buttons.

[dmazzoni, 2015-02-04 08:50:16]

lgtm

Thanks for the nice general solution.

https://codereview.chromium.org/816093002/diff/20001/chrome/browser/resources...
File chrome/browser/resources/chromeos/chromevox/cvox2/background/output.js
(right):

https://codereview.chromium.org/816093002/diff/20001/chrome/browser/resources...
chrome/browser/resources/chromeos/chromevox/cvox2/background/output.js:90:
speak: '!doNotInterrupt' +
is there supposed to be a space after the !doNotInterrupt and before the
@aira_role_alert or does the parser break on a '@'?

[David Tseng, 2015-02-04 16:57:13]

https://codereview.chromium.org/816093002/diff/20001/chrome/browser/resources...
File chrome/browser/resources/chromeos/chromevox/cvox2/background/output.js
(right):

https://codereview.chromium.org/816093002/diff/20001/chrome/browser/resources...
chrome/browser/resources/chromeos/chromevox/cvox2/background/output.js:90:
speak: '!doNotInterrupt' +
On 2015/02/04 08:50:16, dmazzoni wrote:
> is there supposed to be a space after the !doNotInterrupt and before the
> @aira_role_alert or does the parser break on a '@'?

Good catch! The parser splits expressions on spaces.

[David Tseng, 2015-02-04 18:03:35]

New patchsets have been uploaded after l-g-t-m from dmazzoni@chromium.org

[David Tseng, 2015-02-04 18:06:37]

+ sky for ui/views/controls/label.cc

Dominic, PTAL; I'm not sure if Windows, in particular, cares about static text
that expose their text content via "value" vs "name" attributes. On web, we're
currently exposing via value so this change would make Views behave in the same
way.nodes

[David Tseng, 2015-02-04 18:07:05]

dtseng@chromium.org changed reviewers:
+ sky@chromium.org

[David Tseng, 2015-02-04 18:07:06]

+ sky for ui/views/controls/label.cc

Dominic, PTAL; I'm not sure if Windows, in particular, cares about static text
that expose their text content via "value" vs "name" attributes. On web, we're
currently exposing via value so this change would make Views behave in the same
way.nodes

[dmazzoni, 2015-02-04 18:24:12]

On 2015/02/04 18:07:06, David Tseng wrote:
> + sky for ui/views/controls/label.cc
> 
> Dominic, PTAL; I'm not sure if Windows, in particular, cares about static text
> that expose their text content via "value" vs "name" attributes. On web, we're
> currently exposing via value so this change would make Views behave in the
same
> way.nodes

I'd rather not patch ui/views/controls/label.cc. Putting the text of static text
into the "value" rather than the "name" is a WebKit artifact. For now could you
maybe handle it in ChromeVox or in the automation layer, and then we can fix it
in Blink? That was something I was hoping to do when Blink and Chromium are
merged.

[sky, 2015-02-04 19:04:11]

LGTM

[David Tseng, 2015-02-04 21:15:28]

New patchsets have been uploaded after l-g-t-m from sky@chromium.org

[David Tseng, 2015-02-04 21:20:07]

On 2015/02/04 18:24:12, dmazzoni wrote:
> On 2015/02/04 18:07:06, David Tseng wrote:
> > + sky for ui/views/controls/label.cc
> > 
> > Dominic, PTAL; I'm not sure if Windows, in particular, cares about static
text
> > that expose their text content via "value" vs "name" attributes. On web,
we're
> > currently exposing via value so this change would make Views behave in the
> same
> > way.nodes
> 
> I'd rather not patch ui/views/controls/label.cc. Putting the text of static
text
> into the "value" rather than the "name" is a WebKit artifact. For now could
you
> maybe handle it in ChromeVox or in the automation layer, and then we can fix
it
> in Blink? That was something I was hoping to do when Blink and Chromium are
> merged.

I handled it in ChromeVox for now.

[David Tseng, 2015-02-04 21:51:25]

The CQ bit was checked by dtseng@chromium.org

[commit-bot: I haz the power, 2015-02-04 21:51:53]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/816093002/80001

[commit-bot: I haz the power, 2015-02-04 22:55:23]

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

[commit-bot: I haz the power, 2015-02-04 22:55:24]

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

[David Tseng, 2015-02-05 00:21:05]

The CQ bit was checked by dtseng@chromium.org

[commit-bot: I haz the power, 2015-02-05 00:21:42]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/816093002/100001

[commit-bot: I haz the power, 2015-02-05 00:50:00]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2015-02-05 00:53:06]

Patchset 6 (id:??) landed as
https://crrev.com/482aa01deddd1d2e93ebf95b2a0204329c51ae08
Cr-Commit-Position: refs/heads/master@{#314688}