WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Insertion of content into documents.

for

From: Mallory
Date: Jan 7, 2020 4:04AM

>- 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.

Not on its own.
Also, were this to be the case, most news pages would be unusable. Ah, who am I kidding? They currently are often unusable, due to the various chonky 3rd-party ads that take forever to load.

> 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?

No. I mean, if a browser is waiting for any DOM at all then it may not present anything to a screen reader until the user decides to attempt to navigate in (or at least, this is what I've heard in both JAWS and NVDA while testing some single page apps). Sometimes you get an HTML skeleton with a <div id="app"></div> inside. That has the <title> and metadata which might be announced before the JavaScript framework in question finally gets around to filling that "app" div, but otherwise it's silent. On a "normal" page you'd get numbers of headings, links, etc on the page, but I don't always hear these on Single Page Apps.

Developers wanting to have sections that load would manually use aria-busy on the container of the loading content, but support seems thin.

> - Developers inserting the content after an action in the correct position of the DOM which we both touched upon.

Not announced by default. Browsers don't offer anything on their own. Developers would need to hook into an event if you need something after the DOMContentLoaded event (and this event itself doesn't say anything that I'm aware of, although perhaps browsers wait for this before building the a11y tree?).

cheers,
_mallory

On Mon, Jan 6, 2020, at 11:05 PM, Murphy, Sean wrote:
> 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
> > > >
> > > archives at http://webaim.org/discussion/archives
> > > > > >