Dynamic content added above triggering control affects its meaning

[kimviens]

Hello everyone,
I would like to know if someone know under which WCAG criteria would a failure about adding content using JavaScript above a triggering control (in the order of the DOM).

For example, let's say that we have an expandable control that does not use <details> and <summary>. How it works is that there is a paragraph that is truncated. In order to view the whole paragraph, you must activate a "show more" button which is found directly after the truncated paragraph.

Observations:

• Revealing the rest of the paragraph (so untruncating) causes the screen reader to read nothing. No ARIA is used to communicate the appearance of new content above.
• The new content is found above the "show more" button, therefore an adaptive technology user must navigate up to find it.

What success criteria would this fall under?

• 1.3.1 Info and Relationships (Level A)?
• 1.3.2: Meaningful Sequence (Level A)?
• 2.4.3: Focus Order (Level A)?
• 4.1.3: Status Messages (Level AA)?

[kimviens]

Here is an example of what I mentionned above

I am trying to display blog posts that I truncated so that I can show previews. The full post text isn't all visible, only when the user activates a "See more" link that the full blog post text is displayed under the blog post's heading on the same page. Then, the "see more" link text changes to "see less" which can be used to hide the full abstract text.

The "see more" link is placed at the end of each blog post / short preview text block. When activated, a JavaScript injects the full blog post text at the top to amend it to the existing short preview text. The new text is now not in the usual user navigation path, top to bottom.

Keyboard focus remains on the activation link which now changed to "See less", Screen reader users do not hear anything to inform them with any of the changes on the page and the focus is not managed to move automatically to the new content. The next keystroke takes the user to a new blog post block completely missing the new text revealed in the previous one.

There is a business requirement that is preventing me from changing the content structure to a more accessible version. I can only manage the focus to start at the newly revealed content or / and add instructions at the top to inform users of the available options.

Note: the "see more / see less" links are only on the main page and for a quick content preview access, all users can still activate the blog post's link and read the full content.

I want to ask: do you have any recommendations for my situations? What criteria does this fail under? Also should adding dynamic content above the user's reading position be a common failure? Is it possible to get a sufficient technique for this kind of situation or ARIA pattern?

[JAWS-test]

I can't find an SC that is directly violated. Of course, you can interpret criteria broadly and justify a violation (the ones you mentioned fit best). But it's actually difficult:

• 1.3.1 Info and Relationships (Level A) - all information, structure relationships of your content is programmatically determined
• 1.3.2: Meaningful Sequence (Level A)? - the reading sequence of your example is correct
• 2.4.3: Focus Order (Level A) - if the faded-in content does not contain any control, the focus order is not affected
• 4.1.3: Status Messages (Level AA) - the faded-in content is not a status message

Nevertheless, the pattern you mentioned is not optimal for accessibility, even if it is widely used and e.g. users of screen readers should be able to cope with it quite well after a short search. The fact is that the WCAG does not cover all cases of accessibility problems. This means that even if the pattern does not violate the WCAG, it should be avoided.

[alastc]

In practical terms, I think this is the best solution:

I can only manage the focus to start at the newly revealed content

That way the user should find the new content easily, and get to the 'show less' where it makes sense to do so. If it is all pre-loaded it should be quick.

In terms of what does it fail, as Jaws-test commented, not everything that's an issue fails WCAG. (Often because the same thing in a different scenario is not an issue.)

You could maybe make an argument under Meaningful Sequence, as the sequence goes from the top of the content, to the bottom. However, WCAG 2.x doesn't really deal with dynamically updated content, so it's a tricky argument.

[kimviens]

Thank you to the both of you for your responses. I agree, this is not a clear WCAG failure, though this is clearly an accessibility issue. Is it possible to update WCAG to cover more of these situations? Or is it planned that WCAG will never cover all situations?

[patrickhlauke]

I've tended to flag this as a 1.3.2 Meaningful Sequence (Level A) issue (if no focusable elements are present in the content that appears) or 2.4.3 Focus Order (Level A) (if there are focusable elements) in the past. But yes, admittedly 1.3.2 doesn't (currently) say anything about dynamic content (though it probably should acknowledge it...might see if an understanding note could help here)

[mraccess77]

I would tend to flag this as a violation as well since there is no indication of what happened where with the change in reading order. This could be solved many ways to conform though such as by providing instructions, moving focus, etc.

[mbgower]

I concur with the overall statements. Not an ideal situation, but not a clear violation of WCAG.

A few things I'll mention:

1. It is defendable and even arguably logical to keep the focus on the Show more/less button after activation, particularly if there is not anything in the revealed content that could take focus. Imagine if the focus changed based on if something did or not have a focus point in the revealed section. I'm not sure that kind of variability would be looked on as 'better' by many users (and of course the position of item that takes focus inside the new content is not necessarily going to be near the top of the new content).
2. There is also a real challenge in these disclosure patterns about where to place the affordance to expand/collapse. Personally, I think the button is better remaining fixed in position, with the content below the trigger (essentially an accordion).
3. That said, note that behaviour of an accordion is to displace content that follows it. This is a different pattern than, say, expandable content in a tile, where one does not necessarily want to have an expanded tile displace a bunch of tiles around it, which might reorder, and have all manner of odd behaviour. So establishing use case is primary to figuring out the best interaction.
4. There should be ways of implementing the revealed content more accessibly, even with the current interaction model, particularly to screen readers. For example, you could put the content in a polite aria-live region, so that the new content is read after activating the "Show more" button. That could not only allow some people to digest it without necessarily navigating to it, but also cue users that new content had appeared.
5. The "Show more" control, itself, is in some ways descriptive of the action that is going to take place on activiation. If that behaviour is consistent across all the Show mores on a site, users are more likely to figure out ways of surfacing. They may not be ideal, but they would be consistent.

I think the whole concept of truncation, and the various mechanisms common for controlling it, could use a thorough rethink. I wonder what would happen if an actionable inline ellipsis became the affordance, and on activation, instead of disappearing, it remained as an indicator of where the additional text began -- and where it would truncate to afterwards. I even wonder if it's practical to make pressing Esc anywhere within that expanded text area trigger a collapse and return to the ellipsis. Not saying that's the solution. Just musing on other ways of tackling this interaction.

[mbgower]

@kimviens since there appears to be general agreement that it's not really addressed by WCAG 2.2, are you satisfied if we document this as a consideration for WCAG 3?

[patrickhlauke]

i'd still like to try and formulate something relating to meaningful sequence and dynamic changes...

[kimviens]

@mbgower I think I would prefer a little bit of patch work as @patrickhlauke suggested. Because if I have to wait for WCAG 3, I know that I will be waiting for a long time and this is a pitfall that happens more often than rarely.

[fstrr]

This issue is labelled as a discussion, so we’re moving this to Discussions. There doesn’t seem to be an update to make to the documentation, but if that changes, we can move it back to the issues list.