Reflection for ARIA has been discussed a number of times over the years.

Summarizing the general concept of attribute-to-property reflection.

In HTML and other specs, you'll see language such as: ~"The tabIndex DOM property reflects the tabindex content attribute." (Note the camel casing difference for this example.)

What that means is that string value of the DOM Property (myDivElement.tabIndex) always remains in sync with the string value of the Content Attribute (<div tabindex="0">). Initial value in the content attribute is also in the DOM property. Any changes to one are reflected in the other, and vice versa.

There are a number of examples in HTML... invalid, required, etc. There are special name change cases like class/className (class is a reserved keyword in most functional programming languages, etc.) and camelCased examples like tabindex/tabIndex.

Relevance to ARIA

The ARIA Specs have only ever defined Content Attributes, but never DOM properties. This biggest impact of this change would mean that in addition to using the standard attribute manipulation:

// setters
el.setAttribute('role', 'button');
el.setAttribute('aria-label', 'Make it so!');

// getters
el.getAttribute('role'); // returns 'button'
el.getAttribute('aria-label'); // returns 'Make it so!'

…a JavaScript author could also use the direct accessor property shorthand.

// setters
el.role = 'button';
el.ariaLabel = 'Make it so!';

// getters
el.role; // returns 'button'
el.ariaLabel; // returns 'Make it so!'

To my knowledge, every time ARIA reflection has been proposed, it's been met with positive response, but for whatever reason, it's never happened. My recollection is that everyone thinks this is a good idea, but no one was sure what spec it should land in.

The ARIA Spec seems like the most logical place to me, and if the WG agrees, I'm prepared to write the spec portions in a Git branch. I'll fill in some slightly less important contextual info in comments below.