E-mail List Archives
Thread: Insertion of content into documents.
Number of posts in this thread: 6 (In chronological order)
From: Murphy, Sean
Date: Sun, Jan 05 2020 7:53PM
Subject: Insertion of content into documents.
No previous message | Next message →
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
From: Mallory
Date: Mon, Jan 06 2020 3:57AM
Subject: Re: Insertion of content into documents.
← Previous message | Next message →
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
> > > > >
From: Murphy, Sean
Date: Mon, Jan 06 2020 3:05PM
Subject: Re: Insertion of content into documents.
← Previous message | Next message →
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 ADDRESS REMOVED = > On Behalf Of Mallory
Sent: Monday, 6 January 2020 9:58 PM
To: WebAIM Discussion List < = EMAIL ADDRESS 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
> >
From: Mallory
Date: Tue, Jan 07 2020 4:04AM
Subject: Re: Insertion of content into documents.
← Previous message | Next message →
>- 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 ADDRESS REMOVED = > On Behalf Of Mallory
> Sent: Monday, 6 January 2020 9:58 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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
> > > > > >
From: Jonathan Avila
Date: Tue, Jan 07 2020 7:03AM
Subject: Re: Insertion of content into documents.
← Previous message | Next message →
There is a related discussion on the site below about virtual content and accessibility challenges.
https://github.com/WICG/accessible-loading-and-searching-of-content/blob/master/explainer.md
Jonathan
Sent from my iPhone
On Jan 7, 2020, at 6:05 AM, Mallory < = EMAIL ADDRESS REMOVED = > wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
- 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 ADDRESS REMOVED = > On Behalf Of Mallory
Sent: Monday, 6 January 2020 9:58 PM
To: WebAIM Discussion List < = EMAIL ADDRESS 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
From: Murphy, Sean
Date: Tue, Jan 07 2020 3:38PM
Subject: Re: Insertion of content into documents.
← Previous message | No next message
Jonathan
Thanks for the discussion paper.
Sean
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Jonathan Avila
Sent: Wednesday, 8 January 2020 1:04 AM
To: WebAIM Discussion List < = EMAIL ADDRESS 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.
There is a related discussion on the site below about virtual content and accessibility challenges.
https://github.com/WICG/accessible-loading-and-searching-of-content/blob/master/explainer.md
Jonathan
Sent from my iPhone
On Jan 7, 2020, at 6:05 AM, Mallory < = EMAIL ADDRESS REMOVED = > wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
- 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 ADDRESS REMOVED = > On Behalf Of Mallory
Sent: Monday, 6 January 2020 9:58 PM
To: WebAIM Discussion List < = EMAIL ADDRESS 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