E-mail List Archives

Search E-mail List Archives for

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

From: Jim Homme
Date: Tue, Dec 06 2022 1:01PM
Subject: Meaningful Sequende Question
No previous message | Next message →

Hi,
In the page under consideration, there is a link. When the user clicks the link, content appears. Focus jumps to the content. In the HTML order, though, the content is below the footer of the page. When the user hits a Close button, focus jumps back to the link the user originally clicked. The content below the page footer disappears. Question: would you fail the content below the page footer for logical reading order?

Jim

=========Jim Homme
Senior Digital Accessibility Consultant
Bender Consulting Services
412-787-8567
https://www.benderconsult.com/
Support the dreams of independence through employment for students with disabilities with your Amazon purchases.
https://smile.amazon.com/ch/83-0988251

From: Birkir R. Gunnarsson
Date: Tue, Dec 06 2022 6:22PM
Subject: Re: Meaningful Sequende Question
← Previous message | Next message →

If the content is visually presented as a dialog, it should have a
dialog role. If it doesn't I'd fail it under WCAG 4.1.2 for not
presenting its role.
Also, if it isn't a dialog, what happens when you press tab with focus
on the last interactive element in the dialog, where does the focus
end up? Based on that it's possible that I might fail it under 2.4.3,
but failing it under 1.3.2 would be a bit creative.
I think there's a 95%+ chance the content is visually presented a a
dialog/overlay/popover, what have you, and then it needs the dialog
role (+ accessible name and aria-modal="true" if it is modal) for a
screen reader user.



On 12/6/22, Jim Homme < = EMAIL ADDRESS REMOVED = > wrote:
> Hi,
> In the page under consideration, there is a link. When the user clicks the
> link, content appears. Focus jumps to the content. In the HTML order,
> though, the content is below the footer of the page. When the user hits a
> Close button, focus jumps back to the link the user originally clicked. The
> content below the page footer disappears. Question: would you fail the
> content below the page footer for logical reading order?
>
> Jim
>
> =========> Jim Homme
> Senior Digital Accessibility Consultant
> Bender Consulting Services
> 412-787-8567
> https://www.benderconsult.com/
> Support the dreams of independence through employment for students with
> disabilities with your Amazon purchases.
> https://smile.amazon.com/ch/83-0988251
>
> > > > >


--
Work hard. Have fun. Make history.

From: Brooks Newton
Date: Wed, Dec 07 2022 10:27AM
Subject: Re: Meaningful Sequende Question
← Previous message | Next message →

Hi All,

Does anyone have a list of browsers and versions that correctly parse
aria-modal="true" so that the user's Tab sequence is properly constrained
within the container marked up with aria-modal="true" with no additional
custom focus management?

The reason why I ask has everything to do with user outcomes. I understand
that SC 1.3.2 Meaningful Sequence in WCAG 2.x is passed if the Tab sequence
"can be programmatically determined." But just because it "can" doesn't
mean that the proper Tab sequence "will" be set if the browser/user agent
doesn't render the modal content using the content author's intended
interaction pattern.

Do content authors have any assurance that if they use the right page code
to pass SC 1.3.2 the Tab sequence will achieve an accessible result for
users with disabilities who use a keyboard or similar input approach?

Brooks

On Tue, Dec 6, 2022 at 7:22 PM Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> If the content is visually presented as a dialog, it should have a
> dialog role. If it doesn't I'd fail it under WCAG 4.1.2 for not
> presenting its role.
> Also, if it isn't a dialog, what happens when you press tab with focus
> on the last interactive element in the dialog, where does the focus
> end up? Based on that it's possible that I might fail it under 2.4.3,
> but failing it under 1.3.2 would be a bit creative.
> I think there's a 95%+ chance the content is visually presented a a
> dialog/overlay/popover, what have you, and then it needs the dialog
> role (+ accessible name and aria-modal="true" if it is modal) for a
> screen reader user.
>
>
>
> On 12/6/22, Jim Homme < = EMAIL ADDRESS REMOVED = > wrote:
> > Hi,
> > In the page under consideration, there is a link. When the user clicks
> the
> > link, content appears. Focus jumps to the content. In the HTML order,
> > though, the content is below the footer of the page. When the user hits a
> > Close button, focus jumps back to the link the user originally clicked.
> The
> > content below the page footer disappears. Question: would you fail the
> > content below the page footer for logical reading order?
> >
> > Jim
> >
> > =========> > Jim Homme
> > Senior Digital Accessibility Consultant
> > Bender Consulting Services
> > 412-787-8567
> > https://www.benderconsult.com/
> > Support the dreams of independence through employment for students with
> > disabilities with your Amazon purchases.
> > https://smile.amazon.com/ch/83-0988251
> >
> > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > > >

From: Steve Green
Date: Wed, Dec 07 2022 10:35AM
Subject: Re: Meaningful Sequende Question
← Previous message | Next message →

According to the MDN website, the aria-modal="true" attribute is not supposed to do that. They say "Setting aria-modal="true" on dialog and alertdialog role containers indicates the presence of a "modal" element to users of assistive technology, but does not actually make the element modal. The features that make the element actually modal must be implemented by the developer."

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-modal

Steve Green
Managing Director
Test Partners Ltd

From: Brooks Newton
Date: Wed, Dec 07 2022 10:50AM
Subject: Re: Meaningful Sequende Question
← Previous message | Next message →

Thanks for that, Steve. Seems like a missed opportunity to empower user
agents to take on some of the "heavy lifting" developers have to do to
make content accessible. Is MDN the authoritative source for questions
about how markup should work in user agents? Anyone from MDN on this
thread?

Brooks

On Wed, Dec 7, 2022 at 11:35 AM Steve Green < = EMAIL ADDRESS REMOVED = >
wrote:

> According to the MDN website, the aria-modal="true" attribute is not
> supposed to do that. They say "Setting aria-modal="true" on dialog and
> alertdialog role containers indicates the presence of a "modal" element to
> users of assistive technology, but does not actually make the element
> modal. The features that make the element actually modal must be
> implemented by the developer."
>
>
> https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-modal
>
> Steve Green
> Managing Director
> Test Partners Ltd
>
>
>

From: Peter Weil
Date: Wed, Dec 07 2022 11:11AM
Subject: Re: Meaningful Sequende Question
← Previous message | Next message →

Regarding the question of which browsers support aria-modal:

https://caniuse.com/?search=aria-modal

There is also some discussion of aria-modal in Scott O'Hara's excellent update on the dialog element:

https://www.scottohara.me/blog/2019/03/05/open-dialog.html

> On Dec 7, 2022, at 11:50 AM, Brooks Newton < = EMAIL ADDRESS REMOVED = > wrote:
>
> Thanks for that, Steve. Seems like a missed opportunity to empower user
> agents to take on some of the "heavy lifting" developers have to do to
> make content accessible. Is MDN the authoritative source for questions
> about how markup should work in user agents? Anyone from MDN on this
> thread?
>
> Brooks
>
> On Wed, Dec 7, 2022 at 11:35 AM Steve Green < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> According to the MDN website, the aria-modal="true" attribute is not
>> supposed to do that. They say "Setting aria-modal="true" on dialog and
>> alertdialog role containers indicates the presence of a "modal" element to
>> users of assistive technology, but does not actually make the element
>> modal. The features that make the element actually modal must be
>> implemented by the developer."
>>
>>
>> https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-modal
>>
>> Steve Green
>> Managing Director
>> Test Partners Ltd
>>
>>
>>

From: Jeremy Echols
Date: Wed, Dec 07 2022 11:27AM
Subject: Re: Meaningful Sequende Question
← Previous message | Next message →

ARIA attributes are never meant to cause a browser to change its behavior. They're just a way of exposing information. As browsers add / update features, the aria attributes which we used to have to manually hack up become unnecessary. The "dialog" element is a perfect example of this. At some point there won't be any browsers still in use which don't support it, and we'll be able to simply use it without custom JavaScript (beyond the basic stuff like making a button open/close it). We're actually very close to that point already, as all updated browsers do support "dialog" elements very well.

For reference, the url for the "dialog" element follows: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog

From: Steve Green
Date: Wed, Dec 07 2022 11:29AM
Subject: Re: Meaningful Sequende Question
← Previous message | Next message →

MDN aren't the authoritative source, but I assume they have close ties with the Chrome developers, so they should be better informed than most.

The definitive source is https://www.w3.org/TR/wai-aria-1.2/#aria-modal, which says "Assistive technologies MAY limit navigation to the modal element's contents." It doesn't even say SHOULD, let alone MUST, so I expect there is little chance that this will be implemented by enough browsers that authors can rely on it.

Steve

From: Jeremy Echols
Date: Wed, Dec 07 2022 11:34AM
Subject: Re: Meaningful Sequende Question
← Previous message | Next message →

Correct, because it's not up to the assistive technologies to decide how the app should work. The devs need to ensure modals are built right (preferably using the "dialog" element or a polyfill). Assistive technologies can choose to limit navigation if they want, but that can break sites where devs are incorrectly using aria attributes. Which, unfortunately, is quite common.

The correct pattern for a developer *implementing* a modal will not be the same as the requirements of how assistive technologies handle the attribute.

From: Jeremy Echols
Date: Wed, Dec 07 2022 11:36AM
Subject: Re: Meaningful Sequende Question
← Previous message | Next message →

And bear in mind this is about how assistive technologies handle the attribute, not the user agent. So if assistive tech imposes a limit which the unmodified browser doesn't, things can get pretty hairy.

From: Brooks Newton
Date: Wed, Dec 07 2022 11:43AM
Subject: Re: Meaningful Sequende Question
← Previous message | Next message →

Hi Jeremy,

I appreciate your explanation of the role of ARIA markup. I guess that
works out pretty well for browser manufacturers not having to change any of
their wares' behavior based on its presence. How does that work for
developers and users with disabilities? Seems to me like this "not my
problem" approach puts it all back on content owners, who undoubtedly will
interpret what the right thing to do is a number of ways, including many
that don't support access.

Why not make aria-modal into a full-fledged HTML attribute or element
then? Why not handle something as fundamental as focus constraint in modal
content at more centralized source (user agents) for the benefit of
consistency and predictability? Can anyone provide a use case where a
content author marks up a container as modal, but doesn't want focus to be
constrained to that container, unless the user affirmative takes action to
dismiss the modal? If you can think of a case like this, wouldn't that be
the exception and not the rule?

Brooks

On Wed, Dec 7, 2022 at 12:36 PM Jeremy Echols < = EMAIL ADDRESS REMOVED = > wrote:

> And bear in mind this is about how assistive technologies handle the
> attribute, not the user agent. So if assistive tech imposes a limit which
> the unmodified browser doesn't, things can get pretty hairy.
>
>

From: Jeremy Echols
Date: Wed, Dec 07 2022 11:48AM
Subject: Re: Meaningful Sequende Question
← Previous message | Next message →

ARIA attributes were never meant to do work, that's just not why they exist. Browsers do indeed implement these things, as I mentioned: the "dialog" element was built to address this exact problem, and has wide support. ARIA attributes are simply the stopgap so developers are able to build things that browsers can't yet, or shouldn't (such as a custom widget that only makes sense on a single site).

It's not a "not my problem" issue - it's what the w3c explicitly stated about ARIA to begin with. It may behoove you to read W3C's explanation of ARIA rather than cast the blame on browsers who are in fact following the spec precisely.

From: Brooks Newton
Date: Wed, Dec 07 2022 1:30PM
Subject: Re: Meaningful Sequende Question
← Previous message | Next message →

Hey Jeremy (or anyone else who wants to jump into the discussion),

So if ARIA markup was originally intended for AT alone to parse, but some
of the AT role has now been moved to browsers - how does that work in the
case of modal content? I got word on the WAI interest group list that
Assistive Technology (AT) companies are relying upon browsers for at least
some of the accessible code handling that previously was relegated to AT to
handle alone (accessible name calculation), or was that clarification made
in error?

From what I've been hearing recently on these experts lists, I thought
software manufacturers couldn't be forced to do anything they don't want to
do with regard to accessibility support. Is that your understanding? What
happens when folks aren't forced to do anything?

Here are some ideas. Tell me explicitly where I'm wrong and I'll do my best
to learn from your feedback:

- There's no active work going on with the User Agent Accessibility
Guidelines, is there? It's been 6 years since that work ceased. Why?
- There's no more SC 4.1.1. Parsing rule to have worry about in WCAG 2.2
that would point to a shared commitment between content authors, users and
software manufacturers.
- There's all of those pesky "exceptions" in WCAG that excuse known
inaccessible behaviors on the part of browsers, including:
- Disabled controls that fail color contrast requirements that
support access to users with low vision and/or color blindness.
- There's the placeholder attribute, that when implemented according
the default specification creates an inaccessible temporary visual label.
- The exception in WCAG that makes it OK to have low-contrast focus
indicators if it's the browser default styling.
- There's the new WCAG 2.2 rule SC 2.4.13 Focus Not Obscurred that gives
a "pass" for content where only a single pixel of what has focus scrolls
into a view (a shared weakness of a lack of proper markup and appropriate
rendering by user agents).
- There's the same old problem of browsers displaying title text on
mouse hover but not on keyboard focus.
- There's a WCAG 2.x SC 4.1.2 which allows critical accessibility
information to remain "under the hood" and not presented in any mode by the
browser to users with disabilities who don't use AT.

There are a lot more examples that I'm not going to list here. How'd those
exceptions get into the WCAG standard? I served on the WCAG working group
for 4 years and not once did I hear a disability advocate/expert advise the
group to provide exceptions for browsers. Don't get me wrong, I don't work
for the W3C and never have - so I'm not carrying water for them, I'm just
saying I don't have to guess about this point. I know from experience that
exceptions to WCAG don't support user access - they mostly shield software
manufacturers from having to innovate. Am I allowed to have that opinion?

It's all voluntary, right - terms of what browser manufacturers do or don't
do to support access to digital content? At least that's what I've been
hearing on the WAI interest group email list over the past month or so.
Except it's not voluntary for content owners to do whatever they want to
support access in countries, states, provinces, etc. that have adopted WCAG
as part of their laws, right?

Do software manufacturers have actively evolving obligations for supporting
accessibility that have been put forth by the W3C or any other trade
association or advocacy group recently? The User Agent Accessibility
Guidelines (UAAG) have been defunct since 2016, if I'm not mistaken. Why is
it defunct? How about accessibility rules for Authoring Tools? How are
they evolving? Would an updated UAAG specification have assigned greater
responsibility to user agents for handling more of the "heavy lifting"
required by developers to make modal content accessible? That depends on
whether there would be equal representation from the constituents who
define the user experience: content authors, users, software manufacturers
and the standards making body itself.

Who's in charge? Who is overseeing how all of the active participants in
the user experience work together to build and maintain accessible digital
user experiences? Who's making it easier for content authors to deliver
accessible content, and who is doing all they can to remove every last
shred of codified culpability associated with not directly supporting
access to digital content?

It's all very confusing. Maybe you can help clear things up.

Brooks


On Wed, Dec 7, 2022 at 12:48 PM Jeremy Echols < = EMAIL ADDRESS REMOVED = > wrote:

> ARIA attributes were never meant to do work, that's just not why they
> exist. Browsers do indeed implement these things, as I mentioned: the
> "dialog" element was built to address this exact problem, and has wide
> support. ARIA attributes are simply the stopgap so developers are able to
> build things that browsers can't yet, or shouldn't (such as a custom widget
> that only makes sense on a single site).
>
> It's not a "not my problem" issue - it's what the w3c explicitly stated
> about ARIA to begin with. It may behoove you to read W3C's explanation of
> ARIA rather than cast the blame on browsers who are in fact following the
> spec precisely.
>
>

From: Jim Homme
Date: Fri, Dec 09 2022 8:43AM
Subject: Re: Meaningful Sequende Question
← Previous message | No next message

Hi,
I should have said focus order.

=========Jim Homme
Senior Digital Accessibility Consultant
Bender Consulting Services
412-787-8567
https://www.benderconsult.com/
Support the dreams of independence through employment for students with disabilities with your Amazon purchases.
https://smile.amazon.com/ch/83-0988251