Make all ARIA attributes reflected

[Dominic Mazzoni]

This is a complementary proposal to the querySelector one in that it provides an alternative to littering the HTML with lots of ARIA attributes.

In a nutshell, the proposal is that we add JavaScript getters/setters for all ARIA attributes directly on the Element interface (or whatever is the proper interface that handles HTML and SVG elements and anything else where ARIA is allowed).

For most attributes, this will be incredibly straightforward. Instead of:

$('save_button').setAttribute('role', 'button');

You can now write:

$('save_button').role = 'button';

In the case of string attributes, these are reflected both ways, just like "id" and "value" - so if you inspect the DOM, you'd see the 'role' attribute there too.

However, in the case of IDREF attributes, it'd be possible to specify a reference to another valid DOM element that doesn't necessarily have an id, for example:

$('save_button').ariaLabelledBy = [$('save_label')];

In this case, if there was any aria-labelledby attribute in the DOM, it would be deleted. There would not be a way to tell if aria-labelledby is set on this element simply by viewing the element's HTML attributes.

This has a number of similar advantages of the querySelector idea:

* Avoids the need to add ids to so many elements

* Simpler JavaScript

* Potentially helps with shadow DOM

The main difference is that JavaScript is required and there's no way to optimize this away if accessibility is not enabled - but that's not significantly different than how things are today, where apps need to keep updating ARIA attributes even though 99% of the time they're never used.

One objection raised on PFWG was that this could break accessibility testing tools that assume ARIA is found in the HTML alone. Personally I think that's a terrible reason not to do this - any validator that's limited to HTML only and can't dynamically query the browser using a native accessibility API or using JavaScript is going to be out of date and wrong anyway.

- Dominic

[David Bolter]

I think this seems like a good way to go and I agree the testing tool objection shouldn't block.

Cheers,

D

--
You received this message because you are subscribed to the Google Groups "Browser Accessibility Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to browser-accessibil...@googlegroups.com.
To post to this group, send email to browser-acce...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/CAFz-FYxDj1uyXwymOkdGuq%3Dkf8yjPQfXP2naY-cLQ5Q2sAQy9A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Alice Boxhall]

I love this idea, although I wonder if we might benefit from putting all of the ARIA attributes (excluding role?) inside some kind of container, so we'd get something like

$('save_button').aria.labelledBy = [$('save_label')];

This would mean we wouldn't need to balloon out the element interface with every single ARIA attribute.

To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/CAEvucx_p20c62LS%3DobYHRQqRgvU%2BfQBRWYUvTzuGc%3DqPOijrhg%40mail.gmail.com.

[Eitan Isaacson]

On Wed, Mar 11, 2015 at 10:35 AM, 'Dominic Mazzoni' via Browser Accessibility Development <browser-acce...@googlegroups.com> wrote:

This is a complementary proposal to the querySelector one in that it provides an alternative to littering the HTML with lots of ARIA attributes.

In a nutshell, the proposal is that we add JavaScript getters/setters for all ARIA attributes directly on the Element interface (or whatever is the proper interface that handles HTML and SVG elements and anything else where ARIA is allowed).

For most attributes, this will be incredibly straightforward. Instead of:

$('save_button').setAttribute('role', 'button');

You can now write:

$('save_button').role = 'button';

I like this very much indeed. It will make our l10n implementation cleaner.

 

In the case of string attributes, these are reflected both ways, just like "id" and "value" - so if you inspect the DOM, you'd see the 'role' attribute there too.

However, in the case of IDREF attributes, it'd be possible to specify a reference to another valid DOM element that doesn't necessarily have an id, for example:

$('save_button').ariaLabelledBy = [$('save_label')];

In this case, if there was any aria-labelledby attribute in the DOM, it would be deleted. There would not be a way to tell if aria-labelledby is set on this element simply by viewing the element's HTML attributes.

This has a number of similar advantages of the querySelector idea:

* Avoids the need to add ids to so many elements

* Simpler JavaScript

* Potentially helps with shadow DOM

Are there any precedents for this in the DOM API? I'm worried that developers who will be debugging their web apps won't know to look for this since it won't appear in the dev tools DOM inspector as an attribute.

Furthermore, things like DOM mutation observers will probably misbehave. If there were a way to harmonize it, I would love to see this as well.

 

The main difference is that JavaScript is required and there's no way to optimize this away if accessibility is not enabled - but that's not significantly different than how things are today, where apps need to keep updating ARIA attributes even though 99% of the time they're never used.

One objection raised on PFWG was that this could break accessibility testing tools that assume ARIA is found in the HTML alone. Personally I think that's a terrible reason not to do this - any validator that's limited to HTML only and can't dynamically query the browser using a native accessibility API or using JavaScript is going to be out of date and wrong anyway.

- Dominic

[Alice Boxhall]

On Wed, Mar 11, 2015 at 11:08 AM, Eitan Isaacson <eisa...@mozilla.com> wrote:

On Wed, Mar 11, 2015 at 10:35 AM, 'Dominic Mazzoni' via Browser Accessibility Development <browser-acce...@googlegroups.com> wrote:

This is a complementary proposal to the querySelector one in that it provides an alternative to littering the HTML with lots of ARIA attributes.

In a nutshell, the proposal is that we add JavaScript getters/setters for all ARIA attributes directly on the Element interface (or whatever is the proper interface that handles HTML and SVG elements and anything else where ARIA is allowed).

For most attributes, this will be incredibly straightforward. Instead of:

$('save_button').setAttribute('role', 'button');

You can now write:

$('save_button').role = 'button';

I like this very much indeed. It will make our l10n implementation cleaner.

 

In the case of string attributes, these are reflected both ways, just like "id" and "value" - so if you inspect the DOM, you'd see the 'role' attribute there too.

However, in the case of IDREF attributes, it'd be possible to specify a reference to another valid DOM element that doesn't necessarily have an id, for example:

$('save_button').ariaLabelledBy = [$('save_label')];

In this case, if there was any aria-labelledby attribute in the DOM, it would be deleted. There would not be a way to tell if aria-labelledby is set on this element simply by viewing the element's HTML attributes.

This has a number of similar advantages of the querySelector idea:

* Avoids the need to add ids to so many elements

* Simpler JavaScript

* Potentially helps with shadow DOM

Are there any precedents for this in the DOM API? I'm worried that developers who will be debugging their web apps won't know to look for this since it won't appear in the dev tools DOM inspector as an attribute.

Sure: event listeners and styles from style sheets, off the top of my head.

 

Furthermore, things like DOM mutation observers will probably misbehave. If there were a way to harmonize it, I would love to see this as well.

 

The main difference is that JavaScript is required and there's no way to optimize this away if accessibility is not enabled - but that's not significantly different than how things are today, where apps need to keep updating ARIA attributes even though 99% of the time they're never used.

One objection raised on PFWG was that this could break accessibility testing tools that assume ARIA is found in the HTML alone. Personally I think that's a terrible reason not to do this - any validator that's limited to HTML only and can't dynamically query the browser using a native accessibility API or using JavaScript is going to be out of date and wrong anyway.

- Dominic

--
You received this message because you are subscribed to the Google Groups "Browser Accessibility Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to browser-accessibil...@googlegroups.com.
To post to this group, send email to browser-acce...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/CAFz-FYxDj1uyXwymOkdGuq%3Dkf8yjPQfXP2naY-cLQ5Q2sAQy9A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Browser Accessibility Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to browser-accessibil...@googlegroups.com.
To post to this group, send email to browser-acce...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/CAGJkVDEC5wDRSeLveKOpmRWTAqECm_K4fdCdF8SgZNwouHQsNQ%40mail.gmail.com.

[Dominic Mazzoni]

Are there any precedents for this in the DOM API? I'm worried that developers who will be debugging their web apps won't know to look for this since it won't appear in the dev tools DOM inspector as an attribute.

Sure: event listeners and styles from style sheets, off the top of my head.

Also, FWIW, we're working on exposing accessibility information directly in the inspector.

The only alternative I can think of is that the attribute could get some value like '#' when it references some element that doesn't exist.

 

 Furthermore, things like DOM mutation observers will probably misbehave. If there were a way to harmonize it, I would love to see this as well.

There's only two cases I can think of: if it's a simple string attribute, then we will synchronize the attribute and the DOM mutation observers should work fine. If it's a reference to another element, then it's true that you'll no longer be able to use DOM mutation observers to tell if that changed. Is that a concern for Mozilla's internal implementation or for web developers?

[Eitan Isaacson]

On Wed, Mar 11, 2015 at 11:10 AM, Alice Boxhall <abox...@google.com> wrote:

On Wed, Mar 11, 2015 at 11:08 AM, Eitan Isaacson <eisa...@mozilla.com> wrote:

On Wed, Mar 11, 2015 at 10:35 AM, 'Dominic Mazzoni' via Browser Accessibility Development <browser-acce...@googlegroups.com> wrote:

This is a complementary proposal to the querySelector one in that it provides an alternative to littering the HTML with lots of ARIA attributes.

In a nutshell, the proposal is that we add JavaScript getters/setters for all ARIA attributes directly on the Element interface (or whatever is the proper interface that handles HTML and SVG elements and anything else where ARIA is allowed).

For most attributes, this will be incredibly straightforward. Instead of:

$('save_button').setAttribute('role', 'button');

You can now write:

$('save_button').role = 'button';

I like this very much indeed. It will make our l10n implementation cleaner.

 

In the case of string attributes, these are reflected both ways, just like "id" and "value" - so if you inspect the DOM, you'd see the 'role' attribute there too.

However, in the case of IDREF attributes, it'd be possible to specify a reference to another valid DOM element that doesn't necessarily have an id, for example:

$('save_button').ariaLabelledBy = [$('save_label')];

In this case, if there was any aria-labelledby attribute in the DOM, it would be deleted. There would not be a way to tell if aria-labelledby is set on this element simply by viewing the element's HTML attributes.

This has a number of similar advantages of the querySelector idea:

* Avoids the need to add ids to so many elements

* Simpler JavaScript

* Potentially helps with shadow DOM

Are there any precedents for this in the DOM API? I'm worried that developers who will be debugging their web apps won't know to look for this since it won't appear in the dev tools DOM inspector as an attribute.

Sure: event listeners and styles from style sheets, off the top of my head.

Styles will update the attribute, from what I can tell:

$0.style.backgroundColor = 'red';

and then $0.getAttribute('style') will return 'background-color: red;'.

Is there a style field that could take another attribute? That would be interesting.

As for events, do you mean clobbering the onclick attribute from markup? That behavior is strange!

HTMLLabelElement.control and HTMLElement.labels are read-only probably for this reason.

[Dominic Mazzoni]

Sure: event listeners and styles from style sheets, off the top of my head.

Styles will update the attribute, from what I can tell:

$0.style.backgroundColor = 'red';

and then $0.getAttribute('style') will return 'background-color: red;'.

Yes, but that style might be overridden by CSS, you have to call getComputedStyle on it to know the real style. That's why the inspector shows the computed style too.

The solution here is for the inspector to show the computed accessibility attributes, that's what will really help developers.

As for events, do you mean clobbering the onclick attribute from markup? That behavior is strange!

More generally, if I call element.addEventListener('click', onClick) there's no way to tell from the html or even from a JavaScript API that it has a click listener. The onclick attribute is an old deprecated way to do it; a lot of sites now use a content security policy that disallows all inline javascript to help mitigate against attacks.

I was thinking of web developers. The inconsistency could be confusing. For example, a l10n library could rely on dom mutations. If the developer starts referencing elements directly they might end up an out of sync translation.

Only idref attributes would no longer be reflected. Does a l10n library care about things like aria-labelledby or aria-owns? String attributes like aria-label would continue to work fine and fire mutation events.

Also, the workaround for the author is simply to not set these ARIA attributes from JavaScript if they depend on a l10n library that doesn't support them. It's not deprecating any existing behavior, just allowing alternatives.

[Eitan Isaacson]

On Wed, Mar 11, 2015 at 12:10 PM, Dominic Mazzoni <dmaz...@google.com> wrote:

Sure: event listeners and styles from style sheets, off the top of my head.

Styles will update the attribute, from what I can tell:

$0.style.backgroundColor = 'red';

and then $0.getAttribute('style') will return 'background-color: red;'.

Yes, but that style might be overridden by CSS, you have to call getComputedStyle on it to know the real style. That's why the inspector shows the computed style too.

The solution here is for the inspector to show the computed accessibility attributes, that's what will really help developers.

I agree that web developers should never rely on the style attribute for the computed style. And yes, exposing computed accessibility attributes would be a win.

 

As for events, do you mean clobbering the onclick attribute from markup? That behavior is strange!

More generally, if I call element.addEventListener('click', onClick) there's no way to tell from the html or even from a JavaScript API that it has a click listener. The onclick attribute is an old deprecated way to do it; a lot of sites now use a content security policy that disallows all inline javascript to help mitigate against attacks.

That is exactly the issue. The earlier, deprecated, behavior is inconsistent. When you reassign onclick via js it expects a function as opposed to a string and then never updates the attribute in markup. I think that may be a cautionary tale for assigning non-primitive values programmatically.

They solved this issue with 'style' by serializing/deserializing between the DOM field and the attribute. Obviously, node references are much harder to serialize.

I was thinking of web developers. The inconsistency could be confusing. For example, a l10n library could rely on dom mutations. If the developer starts referencing elements directly they might end up an out of sync translation.

Only idref attributes would no longer be reflected. Does a l10n library care about things like aria-labelledby or aria-owns? String attributes like aria-label would continue to work fine and fire mutation events.

Yeah, maybe l10n is a bad example here. I can't think of a better case right now.

 

Also, the workaround for the author is simply to not set these ARIA attributes from JavaScript if they depend on a l10n library that doesn't support them. It's not deprecating any existing behavior, just allowing alternatives.

It's deprecating the ability to observe changes.

I don't feel very strongly about this. I think it would be a neat feature. I'm just wondering if there are alternatives that would harmonize better with DOM API and markup as well as being backward compatible.

[Alice Boxhall]

On Wed, Mar 11, 2015 at 1:21 PM, Eitan Isaacson <eisa...@mozilla.com> wrote:

On Wed, Mar 11, 2015 at 12:10 PM, Dominic Mazzoni <dmaz...@google.com> wrote:

Sure: event listeners and styles from style sheets, off the top of my head.

Styles will update the attribute, from what I can tell:

$0.style.backgroundColor = 'red';

and then $0.getAttribute('style') will return 'background-color: red;'.

Yes, but that style might be overridden by CSS, you have to call getComputedStyle on it to know the real style. That's why the inspector shows the computed style too.

The solution here is for the inspector to show the computed accessibility attributes, that's what will really help developers.

I agree that web developers should never rely on the style attribute for the computed style. And yes, exposing computed accessibility attributes would be a win.

 

As for events, do you mean clobbering the onclick attribute from markup? That behavior is strange!

More generally, if I call element.addEventListener('click', onClick) there's no way to tell from the html or even from a JavaScript API that it has a click listener. The onclick attribute is an old deprecated way to do it; a lot of sites now use a content security policy that disallows all inline javascript to help mitigate against attacks.

That is exactly the issue. The earlier, deprecated, behavior is inconsistent. When you reassign onclick via js it expects a function as opposed to a string and then never updates the attribute in markup. I think that may be a cautionary tale for assigning non-primitive values programmatically.

When you add an event listener programmatically, it doesn't override the event listener added in the attribute, so it's not a matter of not updating that attribute. You end up with both event listeners.

However, there is a valid question around what to do in this case:

<div id="foo" aria-activedescendent="bar" role="menu">

  <div id="bar">Menu item 1</div>

  <div class="selected">Menu item 2</div>

</div>

<script>

$('#foo').aria.activeDescendant = $('#foo').querySelector('.selected');

</script>

- [how] do we reflect the aria-activedescendent attribute at that point? Unlike the event listener case, there can only be one activeDescendant.

[Alice Boxhall]

[Please excuse my odd blind spot around the correct spelling of 'descendent']

[Dominic Mazzoni]

I think the fundamental issue is that an HTML attribute is a really poor way to specify the relationship between two elements, and adding a id to everything is ugly and error-prone. What we have are two competing or complementary proposals for how to make it richer.

1. querySelector - preserves the idea that you can do everything from HTML attributes, but could hurt performance if the developer isn't careful since we never know when a selector might change

2. JavaScript interface for ARIA - makes it much more flexible to express relationships, but at the expense of being able to track ARIA from HTML and DOM APIs alone.

[Dominic Mazzoni]

Also, the workaround for the author is simply to not set these ARIA attributes from JavaScript if they depend on a l10n library that doesn't support them. It's not deprecating any existing behavior, just allowing alternatives.

It's deprecating the ability to observe changes.

It's only removing the ability to observe changes if the web developer chooses to use JavaScript to assign an ARIA relationship attribute. That's why I don't see it as a deprecation; the web developer can choose to not use this feature.

Alternatively, what if we just added a new mutation event type?

[Eitan Isaacson]

On 03/11/2015 01:29 PM, Alice Boxhall wrote:

On Wed, Mar 11, 2015 at 1:21 PM, Eitan Isaacson <eisa...@mozilla.com> wrote:

On Wed, Mar 11, 2015 at 12:10 PM, Dominic Mazzoni <dmaz...@google.com> wrote:

Sure: event listeners and styles from style sheets, off the top of my head.

Styles will update the attribute, from what I can tell:

$0.style.backgroundColor = 'red';

and then $0.getAttribute('style') will return 'background-color: red;'.

Yes, but that style might be overridden by CSS, you have to call getComputedStyle on it to know the real style. That's why the inspector shows the computed style too.

The solution here is for the inspector to show the computed accessibility attributes, that's what will really help developers.

I agree that web developers should never rely on the style attribute for the computed style. And yes, exposing computed accessibility attributes would be a win.

 

As for events, do you mean clobbering the onclick attribute from markup? That behavior is strange!

More generally, if I call element.addEventListener('click', onClick) there's no way to tell from the html or even from a JavaScript API that it has a click listener. The onclick attribute is an old deprecated way to do it; a lot of sites now use a content security policy that disallows all inline javascript to help mitigate against attacks.

That is exactly the issue. The earlier, deprecated, behavior is inconsistent. When you reassign onclick via js it expects a function as opposed to a string and then never updates the attribute in markup. I think that may be a cautionary tale for assigning non-primitive values programmatically.

When you add an event listener programmatically, it doesn't override the event listener added in the attribute, so it's not a matter of not updating that attribute. You end up with both event listeners.

It is not overridden with addEventListener, but if you assigned a function to foo.onclick, it would override the attribute in the markup but not update it. And then you end up in the curious state where the attribute has a value that does not reflect the actual onclick value. In code:

<div id="btn" onclick="alert('foo');"></div>
$('#btn').onclick = function() { alert('bar'); };
// When you press button you will get an alert with "bar" yet when you do:
$('#btn').getAttribute('onclick');
// .. it will return "alert('foo');"

This anomaly probably has no real world consequences, but I think it could still be considered a bad design choice (and probably helped in introducing addEventListener).

However, there is a valid question around what to do in this case:

<div id="foo" aria-activedescendent="bar" role="menu">

  <div id="bar">Menu item 1</div>

  <div class="selected">Menu item 2</div>

</div>

<script>

$('#foo').aria.activeDescendant = $('#foo').querySelector('.selected');

</script>

- [how] do we reflect the aria-activedescendent attribute at that point? Unlike the event listener case, there can only be one activeDescendant.

Yes, that is the dilemma I am concerned about.

[annevk]

On Wednesday, March 11, 2015 at 6:35:54 PM UTC+1, Dominic Mazzoni wrote:

For most attributes, this will be incredibly straightforward. Instead of:

$('save_button').setAttribute('role', 'button');

You can now write:

$('save_button').role = 'button';

I think even here we'd want reflection to known values, probably computed values. Otherwise the value-add would be too low.

 

However, in the case of IDREF attributes, it'd be possible to specify a reference to another valid DOM element that doesn't necessarily have an id, for example:

$('save_button').ariaLabelledBy = [$('save_label')];

In this case, if there was any aria-labelledby attribute in the DOM, it would be deleted. There would not be a way to tell if aria-labelledby is set on this element simply by viewing the element's HTML attributes.

I think it would be better if this was a distinct feature. It doesn't really match any established precedent for HTML attributes.

[David Bolter]

Yeah, turns out ballooning out the element interface is not sitting well with me... I like the container idea. We probably need to sort out how we want to do computed values first? (thanks for started that thread).

Cheers,

D

[Alice Boxhall]

On Fri, Mar 13, 2015 at 2:34 AM, annevk <ann...@annevk.nl> wrote:

On Wednesday, March 11, 2015 at 6:35:54 PM UTC+1, Dominic Mazzoni wrote:

For most attributes, this will be incredibly straightforward. Instead of:

$('save_button').setAttribute('role', 'button');

You can now write:

$('save_button').role = 'button';

I think even here we'd want reflection to known values, probably computed values. Otherwise the value-add would be too low.

I'm not sure I follow - what do you mean by "known values" here?

Regarding exposing computed role as element.role, I think an interface where you can do

var foo = $('#foo');

foo.role = foo.role;

...and end up with a different situation than what you started with, is going to be much more confusing than an interface where you have two distinct methods for getting the role attribute and the computed role value.

  

However, in the case of IDREF attributes, it'd be possible to specify a reference to another valid DOM element that doesn't necessarily have an id, for example:

$('save_button').ariaLabelledBy = [$('save_label')];

In this case, if there was any aria-labelledby attribute in the DOM, it would be deleted. There would not be a way to tell if aria-labelledby is set on this element simply by viewing the element's HTML attributes.

I think it would be better if this was a distinct feature. It doesn't really match any established precedent for HTML attributes.

Personally, I would eventually like to see us deprecate (probably not remove entirely) the ARIA relationship IDREF attributes - they have always been an awkward mechanism. Obviously that's not going to happen any time soon, and certainly not before there are robust alternatives which developers prefer and are comfortable using. However, I don't think we can get around whatever the replacement is (i.e. the "distinct feature" I assume you're referring to) overriding the relationship attribute when they co-exist.

The onclick attribute takes the opposite approach to the one proposed here: setting the element.onclick property to a function in code doesn't remove the attribute, but does override it (e.g. http://jsbin.com/fapegusoju/1/edit?html,js). I think it would be less confusing to simply remove the attribute at that point.

[Anne van Kesteren]

On Fri, Mar 13, 2015 at 5:32 PM, Alice Boxhall <abox...@google.com> wrote:
> On Fri, Mar 13, 2015 at 2:34 AM, annevk <ann...@annevk.nl> wrote:
>> I think even here we'd want reflection to known values, probably computed
>> values. Otherwise the value-add would be too low.
>
> I'm not sure I follow - what do you mean by "known values" here?

The HTML's specification definition for that term.

> Regarding exposing computed role as element.role, I think an interface where
> you can do
>
> var foo = $('#foo');
> foo.role = foo.role;
>
> ...and end up with a different situation than what you started with, is
> going to be much more confusing than an interface where you have two
> distinct methods for getting the role attribute and the computed role value.

Why, that's the exact API we offer for <input>.type. You can use it to
discover which values are supported. It's quite useful.


--
https://annevankesteren.nl/