skip to Main Content

I’m trying to figure out if altering the DOM of a website will present any accessibility problems. I am placing all of the jQuery in a $(document).ready() function. Will this cause any accessibility issues with the altered elements?

We don’t have access to the theme template HTML files, only CSS and JS files. So for example I’m adding a div into our theme using$('[element name]').before('<div>[div content here]</div>') will this content be as accessible as the rest of the DOM as long as I include all the appropriate aria attributes etc.?

2

Answers


  1. In theory, you shouldn’t rely on JavaScript to produce the whole HTML code of your site, it’s basically a bad practice.
    However, it’s exactly how big frameworks like angular and react work.
    Given that 99% of browsers support JavaScript, it’s in fact no longer a problem nowadays.

    The true answer is in fact both yes and no, it depends. It depends on the actual HTML code injected.
    The key point is that, you must have the same care with generated code as with the code directly written in HTML by hand, i.e. be careful on headings, form labels, alt texts, ARIA attributes if you need them, etc. all the time and in particular each time you add/remove something in the DOM. Additionally, you must pay attention to where the focus is or might be and a few other things.

    It’s often overlooked precisely because some people assume that it’s anyway not accessible, what isn’t true.
    In order to be accessible, a site with dynamic contents must be accessible at any moment. If it isn’t always the case, then you will lose users in need of accessibility at some point. In practice the loss of accessibility often happens at the most critical moment: checkout or paiement, maybe not because of your fault if the paiement site isn’t accessible.

    Login or Signup to reply.
  2. You might even improve accessibility by manipulating the DOM via JavaScript (JS). So no, per se, manipulating the DOM does not pose accessibility issues.

    If you cannot control the HTML, and the theme is badly accessible, all you can do to improve that is using JavaScript. Think adding role attributes to generic <div> elements. Also, CSS-only solutions seem appealing, but are often not exposing the appropriate state via ARIA-attributes to assistive technology, which needs to be corrected via JS.

    Whether your manipulations produce problems or improve accessibility, therefore depends strongly on your implementation.

    Here are some examples.

    Adding or Removing Content

    When adding content, like in your example, it depends on where that content is added in the document, and at which moment.

    If it’s being added on DOM Ready, there should be no issue (One exception might be live regions added after the DOM loaded). But if it’s being added at arbitrary moments, it’s problematic.

    The Web Content Accessibility Guidelines (WCAG) refer to this as a Change of Context, which must not happen on focus, on input and on user request

    See A change of content is not always a change of context. Changes in content, such as an expanding outline, dynamic menu, or a tab control do not necessarily change the context, unless they also change one of the above (e.g., focus).

    If it’s being added after DOM Ready, it should happen on user request, or must be a status message and carry the appropriate role to be announced.

    For example, in a Disclosure pattern, the aria-expanded of the trigger indicates that new content will become accessible right after the trigger on pressing it. It might just be added to the DOM, depending on the implementation.

    Lazy Loading Content

    Another, very valid use case would be content that’s added asynchronously. This is tricky to get right, but basically aria-busy can render this more accessible.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search