- From: Adam Cooper <cooperad@bigpond.com>
- Date: Thu, 18 Apr 2024 10:51:28 +1000
- To: "'Brian Lovely'" <brian.lovely.23@gmail.com>, <w3c-wai-ig@w3.org>
- Message-ID: <000801da912a$8c586c30$a5094490$@bigpond.com>
if the change is the result of what people might reasonably assume is ‘navigating to a new page’ (rather than navigation as the narrowly technical concept of requesting a resource), then focus should be applied to the document object. You may want to devise a heuristic for this such as ‘navigation for people occurs when header and foot content remain the same, but body content changes completely’. if the change only modifies a part of a view, then the focus management pattern will be specific to the nature of that change, but, importantly, from the perspective of the people using the view, rather than what a developer can only be bothered to implement as a one-size-fits-all or use-it-again feature. Having said that it is dependent on a particular case, though, there are many common patterns including: * Managing focus in custom widgets using javascript as per ARIA patterns * Moving focus to and from a dialog when it is displayed by user action * Moving focus to and from a dialog when it is system-generated by capturing the currently focused element before the dialog is displayed * Focus is maintained within a dialog that is modal * Maintaining focus on a button when it performs a localised change (e.g., sorting a table, toggling an accordion, incrementing a value, etc.) * Returning focus to a name for a container when the items in that container have been removed completely * Not moving focus to inline error messages or temporary content like toasts The issue with focusing a h1 as an ironclad rule is that, first, there may not actually be a h1 in a given view or, second, that h1 may not actually change with the URl No doubt there’ll be plenty of contrary views about how best to manage focus, but, given that the web is now mature in that there really aren’t that many different ways of doing things at a macro level, it’d be great if WCAG could codify at least the most common focus patterns (more than the 2 or 3 in the techniques, anyway) so that practitioners at least have a fighting chance of applying 2.4.3 consistently and confidently. You may find the ARIA documentation more instructive with regards to managing focus for particular UI patterns than anything in WCAG or a bunch of infinite ‘randos’ on the web. One further thing: because WCAG has become concentrated on testing, if you have the chance, designing focus with UI designers before developers implement unsatisfactory solutions post facto is absolutely essential if you want to do it properly … mapping focus and even tab order in various fidelity wireframes means that developers are then required to implement what is specified rather than badly fix what is broken. From: Brian Lovely <brian.lovely.23@gmail.com> Sent: Tuesday, April 16, 2024 1:59 AM To: w3c-wai-ig@w3.org Subject: Re: Focus on a new page 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 <mailto: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 <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows
Received on Thursday, 18 April 2024 00:51:35 UTC