WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Insertion of content into documents.

for

From: Murphy, Sean
Date: Jan 6, 2020 3:05PM

Mallory

I see the problem in three or four areas at this stage.
- User interaction which you touched upon. This covers notification of new information being made available via ARIA or Focus change.
- Assistive Technology being aware of the DOM being updated. This event change would need to be sent from the browser. Not sure if this occurs. My understanding is Jaws waits for the JavaScript to load or just before it loads. Cannot recall which order it is. So the question here does the browser raise any events via the accessibility API to notify assistive tech of changes to the DOM via dynamic content changes?
- Developers inserting the content after an action in the correct position of the DOM which we both touched upon.

The above are very high overview and more than likely very simplified. Is there anything missing?

Sean


-----Original Message-----
From: WebAIMForum < <EMAIL REMOVED> > On Behalf Of Mallory
Sent: Monday, 6 January 2020 9:58 PM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Insertion of content into documents.

[External Email] This email was sent from outside the organisation – be cautious, particularly with links and attachments.

I wish I knew of a resource (esp one with user testing data) on these things, so I'm also hoping someone answers with a link.

There are a few things I have in mind. Let me know if you have thoughts on them:

- what level is the user's awareness of these kinds of insertions being a normal thing in this? For example if someone's already aware they are in a live collaborative document, then while they're not alerted of things like insertions, they understand that if the revisit an area that's been edited, it may be different.

- if the user Did Something (clicked a button) and its purpose is to show New Stuff, if the button can expose a changed state (often aria-expanded for example), and if users are already aware of how, for example, a disclosure widget pattern works (not everyone does of course), they can (and should be able to) expect the new content to come afterwards. In the simplest examples, if they click a button whose expanded state becomes "expanded" then their first down-arrow would be at the new content. Of course this isn't always the case, especially in dashboards.

- one idea that may satisfy the balance between too much status info and being unaware when stuff's being changed out from under someone is a toggleable live region which only announces that a change has happened (a status noise can be even better, like the system bell), rather than making the new content itself "live". People can then decide if they want to be notified that somewhere Stuff Has Changed or not, which is nicer than deciding on their behalf beforehand.

- sometimes the new content which appears is meant to be the next step for a user. In those cases, moving keyboard focus might be very sensible, even if the rest of the content remains available and users could leave the new section and go back to the main page stuff. This is especially handy with screen magnification, where ARIA live regions aren't announced and something happening on the other end of a dashboard is unlikely to be discovered except by roving around (same with Braille-only). Since moving focus is disruptive, it makes sense to only do this when the task they are doing simply cannot be done in other ways, and they can only either move to a certain next step OR abort. An example is clicking a button which opens a Drawer from the side-- keeping focus on that button makes little sense, and navigating to the Drawer with keyboard, let alone realising where it is, can be difficult. ("Drawer" being those full-height sliding panels often seen on dashboards, for example Jira's
menu.) And there's one reason to click a button to open a Drawer: to look at/act on the stuff in it. Closing that Drawer should probably move focus back to the button on the page which opened it, depending on actions taken in the Drawer, to re-orient.

Those are ideas I think of with these kinds of issues.

cheers,
_mallory



On Mon, Jan 6, 2020, at 3:53 AM, Murphy, Sean wrote:
> All,
>
> I have a general query on the result of inserting new content into the
> DOM for Jaws, NVDA or Voiceover on how they handle the change. As
> there are a lot of web pages which do not correctly handle insertion
> of content. For example, if information is inserted at the bottom of
> the DOM, and the focus is not moved. The user is not aware of this change.
> Likewise, if content is inserted in the middle of the DOM, the same
> behaviour might occur. I am aware ARIA helps here, but isn't
> necessarily the correct approach. Other than the ARIA best practice
> doc, is there any other resources out there which provide good
> examples of handling DOM insertion correctly?
>
> Such as floating panels, page content being updated due to an user
> action, new text being inserted, ETC. The possibilities are endless.
>
> Any guidance on this is more than welcomed.
>
> Sean
> > > archives at http://webaim.org/discussion/archives
> >