ARIA & Progressive Enhancement

[defx]

If an ARIA attribute indicates some behaviour that is only possible via JavaScript, am I right to assume that it is ok (from an accessibility perspective) to add those attributes with JavaScript, rather than including them in the initial HTML?

As an example, let's consider the Accordion Pattern. My assumption is that the best way to approach this would be to ensure that:

• all of the panels are expanded by default in the initial page load and then hidden with JavaScript to avoid rendering any of the content innaccessible
• attributes such as aria-controls are omitted from the initial HTML and then added with JavaScript to avoid being otherwise misleading

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed ARIA & Progressive Enhancement.

The full IRC log of that discussion

<jugglinmike> Subtopic: ARIA & Progressive Enhancement
<jugglinmike> github: https://github.com/w3c/aria-practices/issues/2727
<jugglinmike> Matt_King: Most of the ARIA we add in APG is added dynamically
<siri> Can you add grid for layout issue for our next APG discussion. I need to dropout now
<jugglinmike> jugglinmike: I'm thinking about the Treeview pattern. Right now, if the user views the example with JavaScript disabled, it appears as a broken treeview. Wouldn't it be better to render that content as a list in that case?
<jugglinmike> jugglinmike: It might be better to describe this topic with the term "graceful degradation" rather than "progressive enhancement" because we don't necessarily believe the patterns in APG are "enhancements"
<jugglinmike> Matt_King: I agree that the "graceful degradation" is preferable, but I have more fundamental questions about this. I don't know how realistic it is for screen reader users to browse the web with JavaScript disabled
<jugglinmike> Matt_King: I don't personally browse with JavaScript disabled, so I may be biased, but we haven't typically considered it as a use case
<jugglinmike> jugglinmike: It sounds like what we're saying is: graceful degradation generally takes additional effort, so we would want evidence that the practice would benefit real end-users before making a recommendation in APG...
<jugglinmike> jugglinmike: ...and that we currently don't have evidence that screen reader users browse the web with JavaScript disabled.
<jugglinmike> Matt_King: That sounds right to me. However, this person is asking whether it is okay to make their implementations of the patterns degrade gracefully
<jugglinmike> Matt_King: And to that specific question, I think that yes, it is certainly okay (because that practice does not interfere with the behavior as outlined in APG)
<jugglinmike> Zakim, end the meeting

[mcking65]

Two corrections to the minutes; I intended to say:

• most of the ARIA in APG is embedded in the initial HTML and modified dynamically.
• I've never had a discussion with anyone who relies on accessibility and who claimed it is important that they are able to browse the web with js disabled. I've also never seen any data related to that use case. So, after a few decades of work in this space, I am biased toward thinking it is possible that the use case for needing accessibility without js is now only theoretical and might even be obsolete.

In addition to my comments during the meeting, I believe the origin of the no-js/a11y use case is the early days of WCAG 1.0 when we had more AT that doubled as a user agent and did its own parsing of HTML. AFAIK, while there are still a handful of AT that occasionally parse the DOM to handle edge case specialization (thinking of some eye gaze solutions that customize support for specific web sites), not even those AT expect users to disable js.

The net of today's discussion is:

• The task force is not aware of any negative accessibility side effects of designing code that ensures accessibility degrades gracefully.
• The task force does not know whether effort to ensure graceful degradation of accessibility delivers practical benefits.
• The task force welcomes evidence that clarifies whether or not there is benefit. @defx, does this answer your question?

[defx]

Thanks @mcking65 for the reply, and to everybody else involved in the discussion.

I would like to make some additional points to help clarify my question:

• The reasons for a lack of JavaScript functionality are not limited to, nor most often attributed to, a user choosing to disable JavaScript. A good summary of Progressive Enhancement and the conditions under which JavaScript functionality might be lost can be found here: https://www.gov.uk/service-manual/technology/using-progressive-enhancement. In these scenarios (which I have frequently encountered), parts or all of a page can become innaccessible to all users.
• In the unexpected absence of JavaScript functionality, an ARIA attribute such as “aria-controls” may describe a behaviour that does not exist. My assumption is that, in this scenario, the ARIA attribute would be misleading.
• My question isn’t whether it is ok to dynamically modify ARIA attributes that already exist, but rather if it is ok (from an accessibility standpoint) to wait until JavaScript is running to add ARIA attributes such as aria-controls so as to avoid describing functionality before it is available. For example, if aria-controls is added to an Accordion toggle button after the initial page load, could this change be announced by a screen reader, potentially creating an unnecessary distraction for the user?

[mcking65]

@defx wrote:

• The reasons for a lack of JavaScript functionality are not limited to, nor most often attributed to, a user choosing to disable JavaScript. A good summary of Progressive Enhancement and the conditions under which JavaScript functionality might be lost can be found here: https://www.gov.uk/service-manual/technology/using-progressive-enhancement. In these scenarios (which I have frequently encountered), parts or all of a page can become innaccessible to all users.

Understood. I wonder what portion of leaders in the web engineering community prioritize that approach to resilience. I'm not aware of it often being utilized for commercial sites. Admittedly, my exposure is rather limited, and the philosophy may be different for government services.

• In the unexpected absence of JavaScript functionality, an ARIA attribute such as “aria-controls” may describe a behaviour that does not exist. My assumption is that, in this scenario, the ARIA attribute would be misleading.

Declaring most ARIA states and properties in the HTML will not cause problems for screen reader users. In fact, it could help them understand that the js is not working.

Consider the example of the accordion that you mentioned. In the accordion, aria-controls and aria-expanded are set on a button element. If the js that the button activates is not available, the button will still be a button. If the ARIA attributes are not present, it will be more work for a screen reader user to understand that the button didn't do anything.

Of course, you could leave the HTML button elements out of the accordion and use js to dynamically wrap the inner text of the headings in buttons and then add the ARIA attributes. That's a bunch more js and comes with yet more tradeoffs that go beyond accessibility. Assuming the client side performance is good enough, it shouldn't cause accessibility problems to take this approach.

Generally, there will be accessibility problems with certain roles if js is not loaded. That is a bigger concern than states and properties. For example, widget roles convey expected keyboard behaviors and can automatically switch screen reader settings when they receive focus. For example, JAWS and NVDA change modes when composite widgets receive focus. If the js to listen for kb events is not loaded, that will create a pretty broken experience.

• My question isn’t whether it is ok to dynamically modify ARIA attributes that already exist, but rather if it is ok (from an accessibility standpoint) to wait until JavaScript is running to add ARIA attributes such as aria-controls so as to avoid describing functionality before it is available. For example, if aria-controls is added to an Accordion toggle button after the initial page load, could this change be announced by a screen reader, potentially creating an unnecessary distraction for the user?

Dynamically modifying states and properties, whether setting their value or adding them to an element, will not cause problems.

Adding a role will not cause a problem unless the user has already set focus on that element. It would not be a good idea to change or add a role to any element that is autofocused by the browser.

[defx]

Consider the example of the accordion that you mentioned. In the accordion, aria-controls and aria-expanded are set on a button element. If the js that the button activates is not available, the button will still be a button. If the ARIA attributes are not present, it will be more work for a screen reader user to understand that the button didn't do anything.

I see, that makes perfect sense; If the user finds aria-controls/expanded on the button and then finds that clicking the button doesn’t change state, it is immediately clear that the button isn’t functioning correctly.

Understood. I wonder what portion of leaders in the web engineering community prioritize that approach to resilience. I'm not aware of it often being utilized for commercial sites. Admittedly, my exposure is rather limited, and the philosophy may be different for government services

Very few, in my experience. I think that a larger issue with commercial sites is the use of practices that increase the likelihood of JavaScript not executing, or executing too late, e.g., bundling and/or loading too many scripts on the page, in which case there’s almost certainly more value in tackling those issues before trying to adopt a progressive enhancement strategy.

My own context (when asking the question) is from the perspective of building reusable components that might be used in any project; I’ve been considering how patterns such as those described in the APG can be provided in such a way as to make them easier to reuse. The pattern that I’m leaning towards involves binding to existing HTML, hence the consideration of whether or not adding attributes such as aria-controls at runtime would be an issue. I’m glad to hear that it isn’t, in most cases. Your point with regards to the usefulness of those attributes in the absence of JS functionality however gives me some more food for thought.

Generally, there will be accessibility problems with certain roles if js is not loaded. That is a bigger concern than states and properties. For example, widget roles convey expected keyboard behaviors and can automatically switch screen reader settings when they receive focus. For example, JAWS and NVDA change modes when composite widgets receive focus. If the js to listen for kb events is not loaded, that will create a pretty broken experience.

That’s good to know, and so it would be especially important to ensure that roles don’t exist in the initial HTML for components where ARIA attributes are being added only at runtime.

I think we can safely say that the initial question has been answered! Thank you for taking the time to respond and clarify, this has been most helpful. In closing, I would like to suggest that the APG Accordion pattern be updated to ensure that the panels are not hidden in the HTML so that the content is still accessible in the event that the JavaScript doesn't execute. I would be happy to submit a pull request if you feel that this would be a useful addition.