Re: Focus on a new page

‘It is conflicting guidance and incorrect to put the "default keyboard
focus" on a non-interactive element such as a heading’

The APG on dialog.

then it is advisable to add tabindex="-1" to a static element at the start
of the content and initially focus that element.
https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/


Note

   1. When a dialog opens, focus moves to an element contained in the
   dialog. Generally, focus is initially set on the first focusable element.
   However, the most appropriate focus placement will depend on the nature and
   size of the content. Examples include:
      - If the dialog content includes semantic structures, such as lists,
      tables, or multiple paragraphs, that need to be perceived in order to
      easily understand the content, i.e., if the content would be difficult to
      understand when announced as a single unbroken string, then it
is advisable
      to add tabindex="-1" to a static element at the start of the content
      and initially focus that element. This makes it easier for assistive
      technology users to read the content by navigating the semantic
structures.
      Additionally, it is advisable to omit applying aria-describedby to
      the dialog container in this scenario

Laurence Lewis
Accessibility Senior Specialist-Telstra

On Thu, 18 Apr 2024 at 8:38 AM, Phill Jenkins <pjenkins@us.ibm.com> wrote:

> Please do not conflate the responses from different user types!
> | ... I’ve seen a number of recommendations to programmatically place the
> focus on the h1 (and add tabindex=-1).
> No, not a good idea.
>
> The WCAG success criteria were based on years of research from many
> different types of disabilities users have including users with
> combinations of disabilities.  The criteria are also based on different
> type of content from basic types on informational pages to highly
> interactive web applications.
>
> It is conflicting guidance and incorrect to put the "default keyboard
> focus" on a non-interactive element such as a heading:
> 1. sighted voice command & control users do not want to stop on headings
> because they are not interactive
> 2. sighted keyboard users do not want the tab key to stop on headings that
> are not interactive
> 3. sighted neurodivergent users do not want to be distracted or confused
> when their reading assistant stops on headings as if there is something
> they are now supposed to do but can't
> 4. low vision magnifier users do not want their magnifier to stop on
> headings (moving their view) when there is nothing for them to interact with
> 5. blind screen reader users do not want to *always* stop on every heading
> when navigating the interactive elements.
>
> All users want to be able to always choose to navigate by heading, or by
> interactive control, or by region, or by table, etc.
> and never want the web designer forcing them to stop everywhere, on
> everything, every time they visit the page or application.
>
> _______
> Regards,
>
> Phill Jenkins
> IBM Accessibility, IBM Design
> Equal Access toolkit and accessibility checker at ibm.com/able/
> “Without accessibility, there is no diversity and inclusion of peole with
> disabilities”
>
> -----Original Message-----
> From: Peter Weil <peter.weil@wisc.edu>
> Sent: Wednesday, April 17, 2024 11:09 AM
> To: Brian Lovely <brian.lovely.23@gmail.com>
> Cc: w3c-wai-ig@w3.org
> Subject: [EXTERNAL] Re: Focus on a new page
>
> I’m not sure that there’s a single correct answer to this, but I’ve seen a
> number of recommendations to programmatically place the focus on the h1
> (and add tabindex=-1). Here are a few resources that I found useful:
>
>
> https://www.gatsbyjs.com/blog/2019-07-11-user-testing-accessible-client-routing/
>
> https://johnsweetaccessibility.com/2020/05/accessibility-in-spas-part-2/
>
>
> https://daverupert.com/2019/01/accessible-page-navigations-in-single-page-apps/
>
> https://dev.to/robdodson/managing-focus-64l
>
>
>
> > On Apr 15, 2024, at 10:58 AM, Brian Lovely <brian.lovely.23@gmail.com>
> wrote:
> >
> > I'm curious about this question as it applies to single-page
> applications-style web sites, where the base URL doesn't change, but the
> content of the previous page is "blown away" and replaced by the content of
> the new page. Let's call them pages A and B. If on page A there is a
> control that causes page A to be replaced with page B, then the currently
> focused element is removed from the DOM, along with the rest of page A.
> Screen reader users will hear nothing, and if they try navigating "forward"
> they will be at roughly the same distance from the top of page B as they
> were from the top of page A (that's been my experience, anyway.) Navigating
> forward, they may just encounter the footer, but no matter what they
> encounter it will be confusing to be at some random point in the page B
> content.
> >
> > My question is when changing views in a single-page application-style
> web site, where should focus be placed? I specify "web site" to
> differentiate from a single page application that is simply a series of
> form views.
> >
> > On Fri, Apr 12, 2024 at 7:21 AM Samuel George <
> Samuel.George92@hotmail.com> wrote:
> > Thank you for your response.
> >
> > I am unable to find anywhere in WCAG 2.2 Criterion 2.4.3 Focus Order,
> where it states that forcing a users focus into the main content on a new
> page is a failure, this is the reason I raise the question.
> > The description is the only aspect that would relate to it, however, I
> don’t feel that skipping the <header> when arriving on a new page for
> example, removes operability or meaning in the content, especially when it
> is in a step by step process and you have already encountered the <header>
> which has not changed in these subsequent steps.
> >
> >
> > Kind
> >
> >
> >
> > Sent from Mail for Windows
> >
> >
> >
>
>
>
> --
> Peter Weil
> Web Developer
> University Marketing Web Services
> Office of Strategic Communications
> University of Wisconsin–Madison
> 608-220-3089
>
>
>