E-mail List Archives

You are here: Home > Community > E-mail List Archives > View Thread

Thread: Modal dialogs and page titles

Number of posts in this thread: 5 (In chronological order)

From: Geethavani.Shamanna
Date: Wed, Apr 24 2024 2:58AM
Subject: Modal dialogs and page titles
No previous message | Next message →

Hi all,

I noticed some inconsistent screen reader behaviour when reading the titles of modal dialogs. On accessing the Add Delivery Address dialog on
https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/examples/dialog/
On pressing insert-t, Jaws says 'add delivery address Dialog'. NVDA however reads the page title 'Modal Dialog Example|APG|WAI|W3C' whilst within the dialog.

What is the standard behaviour expected here? Since modals are part of the original page, the developers I am working with argue that the page title should be read out, even when the focus is within the dialog. However, as a screen reader user, I would find it useful if the dialog title is read out whilst the focus is within the dialog.

Insights appreciated.

Many thanks.
Geetha

From: Dean.Vasile@outlook.com
Date: Wed, Apr 24 2024 5:37AM
Subject: Re: Modal dialogs and page titles
← Previous message | Next message →

Expected Behavior:
The ideal behavior is for screen readers to announce the dialog title when focus enters the modal. This provides context and helps the user understand the purpose of the newly opened content.
Reasons for Inconsistency:
* Browser/Screen Reader Differences: How screen readers and browsers interact with dialogs can vary, leading to inconsistent reading of titles.
* Implementation Issues: Even with proper ARIA roles (role="dialog") and labeling (aria-labelledby or aria-label), errors in the code can prevent screen readers from announcing the title correctly.
Developer Argument:
While technically correct that a modal is part of the original page, focusing on the page title when a modal is open is unhelpful for screen reader users. It disrupts the user's flow and doesn't convey the change in context.
Recommendations:
* Prioritize Dialog Title: Ensure that the dialog title (aria-labelledby or aria-label) is announced when focus enters the modal.
* Test Thoroughly: Use a combination of screen readers and browsers to verify that the titles are read as expected.
* Educate Developers: Explain to your developer colleagues why reading the dialog title is crucial for screen reader users. Reference W3C accessibility guidelines for support.
Resources:
* ARIA Dialog Role: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/dialog_role
Let me know if you'd like more clarification!
* https://github.com/jessarcher/jessarcher.com

Dean Vasile

617-799-1162

> On Apr 24, 2024, at 4:58â¯AM, Geethavani.Shamanna < = EMAIL ADDRESS REMOVED = > wrote:
>
> Hi all,
>
> I noticed some inconsistent screen reader behaviour when reading the titles of modal dialogs. On accessing the Add Delivery Address dialog on
> https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/examples/dialog/
> On pressing insert-t, Jaws says 'add delivery address Dialog'. NVDA however reads the page title 'Modal Dialog Example|APG|WAI|W3C' whilst within the dialog.
>
> What is the standard behaviour expected here? Since modals are part of the original page, the developers I am working with argue that the page title should be read out, even when the focus is within the dialog. However, as a screen reader user, I would find it useful if the dialog title is read out whilst the focus is within the dialog.
>
> Insights appreciated.
>
> Many thanks.
> Geetha

From: Birkir R. Gunnarsson
Date: Wed, Apr 24 2024 5:48AM
Subject: Re: Modal dialogs and page titles
← Previous message | Next message →

What is announced when you press the title keyboard shortcut in a screen
reader is up to the screen reader vendor. The developer cannot force one or
the other.

All that the developer can do is to make sure that the page and the dialog
have an accessible name (the <title> element for the page,, aria-labelledby
referencing an element with the dialog title or aria-label on the dialog
element.
Obviously the dialog you tested was fully accessible so the differences you
observed come from the screen reader interpretation of title.

Both Jaws and NVDA have GitHub issue pages where you can file an issue if
you feel the screen reader is not reading the most useful info for the
context. The NVDA GitHub in particular is very responsive and often
generates good discussion.
All you need to file an issue is a GitHub account, and then Google NVDA
GitHub and click "issues" and "new issue".

Let us know if you end up filing one, I am curious to see where that
discussion goes.

On Wed, Apr 24, 2024 at 7:38â¯AM = EMAIL ADDRESS REMOVED = <
= EMAIL ADDRESS REMOVED = > wrote:

> Expected Behavior:
> The ideal behavior is for screen readers to announce the dialog title when
> focus enters the modal. This provides context and helps the user understand
> the purpose of the newly opened content.
> Reasons for Inconsistency:
> * Browser/Screen Reader Differences: How screen readers and browsers
> interact with dialogs can vary, leading to inconsistent reading of titles.
> * Implementation Issues: Even with proper ARIA roles (role="dialog") and
> labeling (aria-labelledby or aria-label), errors in the code can prevent
> screen readers from announcing the title correctly.
> Developer Argument:
> While technically correct that a modal is part of the original page,
> focusing on the page title when a modal is open is unhelpful for screen
> reader users. It disrupts the user's flow and doesn't convey the change in
> context.
> Recommendations:
> * Prioritize Dialog Title: Ensure that the dialog title (aria-labelledby
> or aria-label) is announced when focus enters the modal.
> * Test Thoroughly: Use a combination of screen readers and browsers to
> verify that the titles are read as expected.
> * Educate Developers: Explain to your developer colleagues why reading
> the dialog title is crucial for screen reader users. Reference W3C
> accessibility guidelines for support.
> Resources:
> * ARIA Dialog Role:
> https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/dialog_role
> Let me know if you'd like more clarification!
> * https://github.com/jessarcher/jessarcher.com
>
> Dean Vasile
>
>
> 617-799-1162
>
> > On Apr 24, 2024, at 4:58â¯AM, Geethavani.Shamanna <
> = EMAIL ADDRESS REMOVED = > wrote:
> >
> > Hi all,
> >
> > I noticed some inconsistent screen reader behaviour when reading the
> titles of modal dialogs. On accessing the Add Delivery Address dialog on
> > https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/examples/dialog/
> > On pressing insert-t, Jaws says 'add delivery address Dialog'. NVDA
> however reads the page title 'Modal Dialog Example|APG|WAI|W3C' whilst
> within the dialog.
> >
> > What is the standard behaviour expected here? Since modals are part of
> the original page, the developers I am working with argue that the page
> title should be read out, even when the focus is within the dialog.
> However, as a screen reader user, I would find it useful if the dialog
> title is read out whilst the focus is within the dialog.
> >
> > Insights appreciated.
> >
> > Many thanks.
> > Geetha
> > > > >

--
Work hard. Have fun. Make history.

From: Geethavani.Shamanna
Date: Wed, Apr 24 2024 9:50AM
Subject: Re: Modal dialogs and page titles
← Previous message | Next message →

Thank you, this is very helpful. I will file a bug on the NVDA GitHub page.

Geetha
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Birkir R. Gunnarsson
Sent: Wednesday, April 24, 2024 12:48 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Modal dialogs and page titles

External email: if the sender or content looks suspicious, please click the Report Message icon, or forward it to report-phishing

What is announced when you press the title keyboard shortcut in a screen reader is up to the screen reader vendor. The developer cannot force one or the other.

All that the developer can do is to make sure that the page and the dialog have an accessible name (the <title> element for the page,, aria-labelledby referencing an element with the dialog title or aria-label on the dialog element.
Obviously the dialog you tested was fully accessible so the differences you observed come from the screen reader interpretation of title.

Both Jaws and NVDA have GitHub issue pages where you can file an issue if you feel the screen reader is not reading the most useful info for the context. The NVDA GitHub in particular is very responsive and often generates good discussion.
All you need to file an issue is a GitHub account, and then Google NVDA GitHub and click "issues" and "new issue".

Let us know if you end up filing one, I am curious to see where that discussion goes.

On Wed, Apr 24, 2024 at 7:38â¯AM = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > wrote:

> Expected Behavior:
> The ideal behavior is for screen readers to announce the dialog title
> when focus enters the modal. This provides context and helps the user
> understand the purpose of the newly opened content.
> Reasons for Inconsistency:
> * Browser/Screen Reader Differences: How screen readers and browsers
> interact with dialogs can vary, leading to inconsistent reading of titles.
> * Implementation Issues: Even with proper ARIA roles (role="dialog")
> and labeling (aria-labelledby or aria-label), errors in the code can
> prevent screen readers from announcing the title correctly.
> Developer Argument:
> While technically correct that a modal is part of the original page,
> focusing on the page title when a modal is open is unhelpful for
> screen reader users. It disrupts the user's flow and doesn't convey
> the change in context.
> Recommendations:
> * Prioritize Dialog Title: Ensure that the dialog title
> (aria-labelledby or aria-label) is announced when focus enters the modal.
> * Test Thoroughly: Use a combination of screen readers and browsers
> to verify that the titles are read as expected.
> * Educate Developers: Explain to your developer colleagues why
> reading the dialog title is crucial for screen reader users. Reference
> W3C accessibility guidelines for support.
> Resources:
> * ARIA Dialog Role:
> https://deve/
> loper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FAccessibility%2FARIA%2FRoles%
> 2Fdialog_role&data%7C02%7Cgeethavani.shamanna%40open.ac.uk%7C0ad47b
> ee80e64f861cf708dc64548211%7C0e2ed45596af4100bed3a8e5fd981685%7C0%7C0%
> 7C638495561348039186%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
> joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Wh6SB5Skf
> 9%2B6Vo8vaVTNO3tOwMTWzzXAy%2BuSHvjAXmw%3D&reserved=0
> Let me know if you'd like more clarification!
> *
> https://gith/
> ub.com%2Fjessarcher%2Fjessarcher.com&data%7C02%7Cgeethavani.shamann
> a%40open.ac.uk%7C0ad47bee80e64f861cf708dc64548211%7C0e2ed45596af4100be
> d3a8e5fd981685%7C0%7C0%7C638495561348053532%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
> C%7C%7C&sdata=txe%2Fuqu9PgiXGp%2F2IR2clw1%2Fhm5JbXG4%2FIf9zwXY1K4%3D&r
> eserved=0
>
> Dean Vasile
>
>
> 617-799-1162
>
> > On Apr 24, 2024, at 4:58â¯AM, Geethavani.Shamanna <
> = EMAIL ADDRESS REMOVED = > wrote:
> >
> > Hi all,
> >
> > I noticed some inconsistent screen reader behaviour when reading the
> titles of modal dialogs. On accessing the Add Delivery Address dialog
> on
> > https://ww/
> > w.w3.org%2FWAI%2FARIA%2Fapg%2Fpatterns%2Fdialog-modal%2Fexamples%2Fd
> > ialog%2F&data%7C02%7Cgeethavani.shamanna%40open.ac.uk%7C0ad47bee8
> > 0e64f861cf708dc64548211%7C0e2ed45596af4100bed3a8e5fd981685%7C0%7C0%7
> > C638495561348065744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ
> > IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=dZ%2FW
> > rapoVIlaNwnXEXdlXeI03zCGdOW7LRW6HcptjKo%3D&reserved=0
> > On pressing insert-t, Jaws says 'add delivery address Dialog'. NVDA
> however reads the page title 'Modal Dialog Example|APG|WAI|W3C' whilst
> within the dialog.
> >
> > What is the standard behaviour expected here? Since modals are part
> > of
> the original page, the developers I am working with argue that the
> page title should be read out, even when the focus is within the dialog.
> However, as a screen reader user, I would find it useful if the dialog
> title is read out whilst the focus is within the dialog.
> >
> > Insights appreciated.
> >
> > Many thanks.
> > Geetha
> > > http://list/.
> webaim.org%2F&data%7C02%7Cgeethavani.shamanna%40open.ac.uk%7C0ad47b
> ee80e64f861cf708dc64548211%7C0e2ed45596af4100bed3a8e5fd981685%7C0%7C0%
> 7C638495561348074139%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
> joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=6wsHfI5Zw
> Uxe7ZtKvOEcisvE23a17CiFqn8mV%2BtzfNo%3D&reserved=0
> List archives at
> http://webai/
> m.org%2Fdiscussion%2Farchives&data%7C02%7Cgeethavani.shamanna%40ope
> n.ac.uk%7C0ad47bee80e64f861cf708dc64548211%7C0e2ed45596af4100bed3a8e5f
> d981685%7C0%7C0%7C638495561348079817%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C
> &sdata=yQJU9%2BuxuGwy1S4%2BQ6GUn0iPw2ISWAS%2FHQzaPr1DnMw%3D&reserved=0
> >

--
Work hard. Have fun. Make history.

From: Brooks Newton
Date: Thu, Apr 25 2024 9:44AM
Subject: Re: Modal dialogs and page titles
← Previous message | No next message

Hi All,

You won't find answers to specific implementation approaches in my post,
but you might find some useful ideas on how our industry might better
handle the issue of inconsistent accessibility support in the text that
follows.

How would coming together as an industry and developing standard
cross-browser, cross-screen reader, cross-platform, cross-disability
conventions for modal content patterns work?

Any problem with that? Who would host this meeting? Would it be public?
Who gets real seats at the table? Who's invited just for the show? Who has
the power to compel this to happen? Who will look for every reason and
spend enormous resources to be excluded from responsibility to directly
supporting the disability community?

Why are these issues related to fixing the user experience for people with
disabilities now relegated to GitHub-based activism? Does everyone with a
stake in digital accessibility have to be a developer (or hire a developer)
to get traction on closing gaps in access? It seems like developers don't
have a lot of power to change things, as some have noted. Maybe developers
are the wrong people to rely upon when the access problem requires
foundational change to properly address?

Shouldn't these issues be addressed at a deeper level, like at a standards
level or even legal mandates? Then, technology would be tasked to figure
out how to make their languages, frameworks, platforms and software fit the
primary need as identified by the disability community. This, I think,
would work to better ensure broad-based, affordable access. It would work
better rather than telling the disability community that the all-important
technology comes first and that its application to provide access to human
beings with disabilities will have to be shoehorned in as an afterthought?
This fantasy system would rely on key parties working together from the
start so that there is at least an attempt at honest consensus?

As an accessibility consultant for some of the biggest companies on planet
earth, I've implored my managers to build accessibility into projects from
the earliest possible point in the project lifecycle. I would encourage
whoever is creating the technology building blocks (languages, protocols,
standards, regulations, etc.) to do the same with careful consultation from
stakeholders across the spectrum. I have a running personal list of
phenomena that seem like institutionalized inaccessibility. This list
includes items such as the way that some browsers handle placeholder
labels, low contrast display of disabled content, display of title text on
keyboard focus versus mouse hover, etc.

Then there are the baked-in excuses for software that fails to support
access, which appear in WCAG and in some laws (Section 508 Refresh) that
have adopted WCAG as part of its regulatory framework. Ever notice how
many disclaimers appear in the "Understanding" documents for WCAG that give
content owners the excuse not to count access failures in accessibility
reports when the software is at fault? Notice how the most popular way
folks on this forum advocate for fixing the software errors is to file a
bug ticket? How has that worked out? Everyone OK with accepting this and
not pushing for more? Ever see a fundamental bug that limits access sit in
a bug queue for years? I have.

Some of the institutionalized inaccessibility is baked into the
specifications for markup, some of it is baked into the laws that exclude
software and other technologies from having to comply with regulatory
requirements, some of the inaccessibility is baked into templates,
frameworks and design systems that get it wrong from the get-go, even
though guidance for access was available years before these technologies
were created and distributed to commercial interests and the unsuspecting
public.

Why is there no pre-approved list of design patterns that laws and
regulations require software vendors to handle consistently in a manner
that supports access to blind users and other users with disabilities who
are impacted? I've worked with so many companies who are willing to do the
right thing to support access, if they could only be assured that all parts
of the puzzle were obligated to support the disability community by
establishing a commitment to a common standard that guides each in taking
positive steps to do their parts for the things they control.

I'm not suggesting that all browsers or assistive technology (AT) handle
content exactly the same. Nor am I suggesting that all users will have to
navigate, interact or consume content the same way. What I'm suggesting
is, however, that there need to be a bare minimum set of foundational
requirements and consequences for non-compliance that map out roles and
responsibilities for content owners/production workers, browsers/AT
manufacturers, standards bodies and users.

Right now, the vast majority responsibility is heaped onto content owners
and their production crews, who do not control enough of the variables at
play to be solely responsible for creating accessible digital content
experiences.

Brooks Newton

On Wed, Apr 24, 2024 at 6:48â¯AM Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> What is announced when you press the title keyboard shortcut in a screen
> reader is up to the screen reader vendor. The developer cannot force one or
> the other.
>
> All that the developer can do is to make sure that the page and the dialog
> have an accessible name (the <title> element for the page,, aria-labelledby
> referencing an element with the dialog title or aria-label on the dialog
> element.
> Obviously the dialog you tested was fully accessible so the differences you
> observed come from the screen reader interpretation of title.
>
> Both Jaws and NVDA have GitHub issue pages where you can file an issue if
> you feel the screen reader is not reading the most useful info for the
> context. The NVDA GitHub in particular is very responsive and often
> generates good discussion.
> All you need to file an issue is a GitHub account, and then Google NVDA
> GitHub and click "issues" and "new issue".
>
> Let us know if you end up filing one, I am curious to see where that
> discussion goes.
>
>
> On Wed, Apr 24, 2024 at 7:38â¯AM = EMAIL ADDRESS REMOVED = <
> = EMAIL ADDRESS REMOVED = > wrote:
>
> > Expected Behavior:
> > The ideal behavior is for screen readers to announce the dialog title
> when
> > focus enters the modal. This provides context and helps the user
> understand
> > the purpose of the newly opened content.
> > Reasons for Inconsistency:
> > * Browser/Screen Reader Differences: How screen readers and browsers
> > interact with dialogs can vary, leading to inconsistent reading of
> titles.
> > * Implementation Issues: Even with proper ARIA roles (role="dialog") and
> > labeling (aria-labelledby or aria-label), errors in the code can prevent
> > screen readers from announcing the title correctly.
> > Developer Argument:
> > While technically correct that a modal is part of the original page,
> > focusing on the page title when a modal is open is unhelpful for screen
> > reader users. It disrupts the user's flow and doesn't convey the change
> in
> > context.
> > Recommendations:
> > * Prioritize Dialog Title: Ensure that the dialog title (aria-labelledby
> > or aria-label) is announced when focus enters the modal.
> > * Test Thoroughly: Use a combination of screen readers and browsers to
> > verify that the titles are read as expected.
> > * Educate Developers: Explain to your developer colleagues why reading
> > the dialog title is crucial for screen reader users. Reference W3C
> > accessibility guidelines for support.
> > Resources:
> > * ARIA Dialog Role:
> >
> https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/dialog_role
> > Let me know if you'd like more clarification!
> > * https://github.com/jessarcher/jessarcher.com
> >
> > Dean Vasile
> >
> >
> > 617-799-1162
> >
> > > On Apr 24, 2024, at 4:58â¯AM, Geethavani.Shamanna <
> > = EMAIL ADDRESS REMOVED = > wrote:
> > >
> > > Hi all,
> > >
> > > I noticed some inconsistent screen reader behaviour when reading the
> > titles of modal dialogs. On accessing the Add Delivery Address dialog on
> > > https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/examples/dialog/
> > > On pressing insert-t, Jaws says 'add delivery address Dialog'. NVDA
> > however reads the page title 'Modal Dialog Example|APG|WAI|W3C' whilst
> > within the dialog.
> > >
> > > What is the standard behaviour expected here? Since modals are part of
> > the original page, the developers I am working with argue that the page
> > title should be read out, even when the focus is within the dialog.
> > However, as a screen reader user, I would find it useful if the dialog
> > title is read out whilst the focus is within the dialog.
> > >
> > > Insights appreciated.
> > >
> > > Many thanks.
> > > Geetha
> > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > > >