This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
+++ This bug was initially created as a clone of Bug #23365 +++ "Let control be the first element in tree order whose nearest ancestor dialog element is subject and that has an autofocus attribute specified, if any." modify this so that focus moves by default(does not need author to do). this will make it much better for keyboard/screen reader/screen mag users.
I have no idea what this means. Can you elaborate?
(In reply to Ian 'Hixie' Hickson from comment #1) > I have no idea what this means. Can you elaborate? The steps for dialog.showModal[1] include: "Let control be the first element in tree order whose nearest ancestor dialog element is subject and that has an autofocus attribute specified, if any. If there is no control, then abort these steps. Run the focusing steps for control." [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#dom-dialog-showmodal This means if no focusable element has autofocus, the dialog won't get focus when shown (in Blink currently, <body> gets focus). The proposal is to change that behavior so that an element in the dialog (or the dialog itself) gets focus even without using autofocus. There is also discussion on Bug #23365 and http://crbug.com/298079
data point: alert() and confirm() modal dialogs move focus to a/the control within the dialog box in IE/Chrome/Firefox on windows
(In reply to steve faulkner from comment #3) > data point: > alert() and confirm() modal dialogs move focus to a/the control within the > dialog box in IE/Chrome/Firefox on windows as does prompt(). window.open moves focus to the new window.
Why do we need this for <dialog> but not new windows? I'm confused. What's special about <dialog>?
(In reply to Ian 'Hixie' Hickson from comment #5) > Why do we need this for <dialog> but not new windows? I'm confused. What's > special about <dialog>? test window.open, where does the focus move? to the new window author needs to do nothing , the behavior is built in, not currently same for dialog.
When you do window.open() the focus moves to the document.body, right? Same as with <dialog>? I don't understand the issue.
body of new winow(In reply to Ian 'Hixie' Hickson from comment #7) > When you do window.open() the focus moves to the document.body, right? Same > as with <dialog>? I don't understand the issue. body of new window not body of current window
Yes, body of the new window. Same as here (where the "new window" is the same window). Why is it ok for the body to be focused when the page consists of just a form, but it's not ok when the page consists of just a form in a <dialog>?
(In reply to Ian 'Hixie' Hickson from comment #9) > Yes, body of the new window. Same as here (where the "new window" is the > same window). > > Why is it ok for the body to be focused when the page consists of just a > form, but it's not ok when the page consists of just a form in a <dialog>? when a new window is opened AT will generally announce the presence of the new window, start reading the content of the document in the new window. This is not the case for your proposed behaviour as the focus is simply moving to a new location in the current page. Moving focus to the dialog triggers the desired behaviour (presence of dialog is announced and content of the dialog is announced), moving to the body of the current document does not. For screen mags (depending on mag level) moving focus to the body does not result in the dialog being in the viewport, users will have no idea the dialog has appeared. if focus is moved to the dialog then it becomes visible regardless of screen magnification level. As pointed out comment 3 this is different behaviour than for alert(),confirm() and prompt() Why have a different behaviour from these? What is the advantage of moving to the body rather than the dialog? The
I'm not so familiar with AT, but another thing to consider is if the dialog has a long chain of ancestors. If focus goes to document.body, would you have to navigate through its ancestors to reach the dialog? Something like: <body> <div> <div> <div> <dialog> I'm guessing the <div>s would be skipped over since they have no content themselves. Text nodes would not be ancestors of dialog. Making the divs focusable with tabindex would be problematic, but that's a bit contrived.
(In reply to Matt Falkenhagen from comment #11) > I'm not so familiar with AT, but another thing to consider is if the dialog > has a long chain of ancestors. If focus goes to document.body, would you > have to navigate through its ancestors to reach the dialog? > > Something like: > > <body> > <div> > <div> > <div> > <dialog> > > I'm guessing the <div>s would be skipped over since they have no content > themselves. Text nodes would not be ancestors of dialog. Making the divs > focusable with tabindex would be problematic, but that's a bit contrived. Note that screen readers generally have cursor key that allows users to move through content, so in the case you presented above if it included text nodes these would be presented and navigable by the user as would any interactive controls (though they would not be actionable): <body> <div> text <a href="#">blah</a> <div> text blah <div> text blah <dialog> This seems like a simple point of author failure that would be less of a problem if focus was moved to the <dialog> when it is displayed.
looked at a range of modal dialog scripts: http://jqueryui.com/dialog/#modal http://bootboxjs.com/ http://dojotoolkit.org/reference-guide/1.9/dijit/Dialog.html http://yuilibrary.com/yui/docs/panel/panel-form-example.html http://www.accessiblemootoolsdemo.iao.fraunhofer.de/Mootools_Widgets/index.html any modal dialogs in google gmail/drive etc. http://docs.sencha.com/extjs/4.2.1/extjs-build/examples/message-box/msg-box.html http://www.gwt-ext.com/demo/#messageBox all of the above have one thing in common. They move focus to the dialog or a control in the dialog.
Presumably moving focus to the dialog would also mean HTML-dialog maps to ARIA more easily: http://www.w3.org/TR/wai-aria/roles#dialog
This move would also make things easier for authors. As far as I'm concerned, focus for dialogs is definitive. That is, if focus is not required, it is simply an alert, and we already have role="alert".
(In reply to steve faulkner from comment #12) > Note that screen readers generally have cursor key that allows users to move > through content, so in the case you presented above if it included text > nodes these would be presented and navigable by the user as would any > interactive controls (though they would not be actionable): > > <body> > <div> text <a href="#">blah</a> > <div> text blah > <div> text blah > <dialog> But the text nodes would be inert in these cases. They are children of the <div>s and not ancestors of the <dialog>. So AT should recognize them as inert, right? (I think I agree to move focus to the dialog, but am just pointing this out.)
(In reply to Matt Falkenhagen from comment #16) > But the text nodes would be inert in these cases. They are children of the > <div>s and not ancestors of the <dialog>. So AT should recognize them as > inert, right? > > (I think I agree to move focus to the dialog, but am just pointing this out.) Text nodes are not marked as inert regardless (their container elements are). for example: in dump from chrome acc tree: the pre element is marked as inert (unavailable) its text node (ROLE_SYSTEM_TEXT) is not. IA2_ROLE_SECTION UNAVAILABLE READONLY display:block tag:pre role_name='pre' location=(91, -303) size=(1171, 37) index_in_parent=5 n_relations=0 n_characters=35 caret_offset=0 n_selections=0 ROLE_SYSTEM_TEXT name='<dialog>This is da dialog!</dialog>' name='<dialog>This is da dialog!</dialog>' READONLY display:block location=(100, -291) size=(246, 14) index_in_parent=0 n_relations=0 n_characters=35 caret_offset=0 n_selections=0
(In reply to Ian 'Hixie' Hickson from comment #9) > Yes, body of the new window. Same as here (where the "new window" is the > same window). > > Why is it ok for the body to be focused when the page consists of just a > form, but it's not ok when the page consists of just a form in a <dialog>? Focus() not only moves document focus, it fires a system focus notification that is relied upon by keyboard users, zoom users, and screen reader users. If this focus notification comes in on the wrong element, the element ref and screen coordinates will be wrong, and the applications that rely on these details will not work as expected. If you’re displaying a form that is intended to be modal, it must get keyboard focus in order to work like a modal dialog on *any* platform that supports keyboard focus.
(In reply to steve faulkner from comment #10) > > when a new window is opened AT will generally announce the presence of the > new window, start reading the content of the document in the new window. > This is not the case for your proposed behaviour as the focus is simply > moving to a new location in the current page. When show() or showModal() is called, a sane browser with an AT would tell the user. It would be dumb not to tell the user. However, that's UI behaviour, and is up to the user. That has nothing to do with the focus. > Moving focus to the dialog-- ...wouldn't be possible since the <dialog> element isn't focusable in the first place, according to the spec today. (In reply to Matt Falkenhagen from comment #11) > > I'm guessing the <div>s would be skipped over Skipped over when doing what? (In reply to steve faulkner from comment #12) > > Note that screen readers generally have cursor key that allows users to move > through content, so in the case you presented above if it included text > nodes these would be presented and navigable by the user as would any > interactive controls (though they would not be actionable) That would be non-conforming, since the spec says "When a node or one of its ancestors is inert, then the user agent must act as if the element was absent for the purposes of targeting user interaction events, may ignore the node for the purposes of text search user interfaces (commonly known as "find in page"), and may prevent the user from selecting text in that node". (In reply to steve faulkner from comment #13) > http://jqueryui.com/dialog/#modal Focuses the close button. > http://bootboxjs.com/ Focuses a button. > http://dojotoolkit.org/reference-guide/1.9/dijit/Dialog.html Focuses the close button. > http://yuilibrary.com/yui/docs/panel/panel-form-example.html Focuses the dialog, though the dialog has no keyboard event listener, so it's not clear why. > http://www.accessiblemootoolsdemo.iao.fraunhofer.de/Mootools_Widgets/index. > html Focuses a text field. The elements that form the dialog itself aren't actually focusable. > http://docs.sencha.com/extjs/4.2.1/extjs-build/examples/message-box/msg-box. > html Focuses a button. > http://www.gwt-ext.com/demo/#messageBox Focuses a button. The dialog itself isn't focusable. > all of the above have one thing in common. They move focus to the dialog or > a control in the dialog. All of them but one have one thing in common: They move focus to a control. That's what <dialog> does too -- it moves focus to the first element with the autofocus="" attribute. Several of them do allow the dialog itself to be focused, though it's not clear to me why. However, several of them do that by actually making an ancestor focusable, not the dialog itself, and that's again what the <dialog> spec does: the <body> ancestor is focusable, and the rest of the document is inert. (In reply to steve faulkner from comment #17) > > Text nodes are not marked as inert regardless Then that's a bug. The spec says they are. (In reply to James Craig from comment #18) > > Focus() not only moves document focus, it fires a system focus notification > that is relied upon by keyboard users, zoom users, and screen reader users. Sure. showModal() should definitely do that. It would be dumb not to. But that's a UI issue. It is orthogonal to document.activeElement. > If you’re displaying a form that is intended to be modal, it must get > keyboard focus in order to work like a modal dialog on *any* platform that > supports keyboard focus. There is no observable difference between the <dialog> element having focus and the <body> element having focus, except that if we allowed the <dialog> element to be focused, and you then nested them, it would mean you could make an ancestor <dialog> have focus, which would be inconsistent with modal dialogs on other platforms. I could see several arguments: - maybe we should find a way to make <dialog>s focusable, yet inert again when a descendant <dialog> is modal. This in particular might be helpful with non- modal <dialog>s since right now there's no way to focus them. - maybe we should focus the first control of a <dialog> if none are marked with autofocus="", when a <dialog> is shown by showModal(). However neither of those have to do with ATs, which are already quite able to do the right thing here, and neither of those things are what this bug is ostensibly about.
(In reply to Ian 'Hixie' Hickson from comment #19) what this bug is about was stated in comment 2 >The proposal is to change that behavior so that an element in the dialog (or the >dialog itself) gets focus even without using autofocus. >All of them but one have one thing in common: They move focus to a control. >That's what <dialog> does too -- it moves focus to the first element with the >autofocus="" attribute. there is one obvious difference that you appear to have strategically overlooked: All of the examples move focus without the author having to set the focus i.e. by default. as do the javascript alert(), confirm(), prompt() dialogs. <dialog> does not do this unless the author adds the attribute.
(In reply to Ian 'Hixie' Hickson from comment #19) > > http://yuilibrary.com/yui/docs/panel/panel-form-example.html > > Focuses the dialog, though the dialog has no keyboard event listener, so > it's not clear why. For at least three reasons: 1. So a keyboard user's focus is at the beginning of the dialog (e.g. pressing tab will move to the first focusable node inside the dialog) 2. So a system focus notification will fire, and like Zoom windows will move to the right screen coordinates. 3. So screen readers will move their cursor (or "focus") into the dialog based on the "focus changed" notification. It's ridiculously expensive to constantly monitor whether a dialog appeared somewhere. It's much less expensive to listen for focus notifications and then run up the ancestor chain to see if you're in a dialog. You could propose a new "dialog opened" accessibility notification in every platform API, but all of them are currently expecting the browsers and apps to do this through standard focus notifications, because they are useful for non-AT users, too.
(In reply to Ian 'Hixie' Hickson from comment #19) > > all of the above have one thing in common. They move focus to the dialog or > > a control in the dialog. > > All of them but one have one thing in common: They move focus to a control. > That's what <dialog> does too -- Not exactly, as you say: > it moves focus to the first element with > the autofocus="" attribute. So it only moves to a control that has the autofocus attr set. I propose it should: 1. Moves focus to the first element with the autofocus="" attribute. 2. If #1 is not found, moves focus to the first focusable element. 3. If #2 is not found, moves focus to the dialog element itself which, if not already focusable, temporarily assumes a tabIndex value of -1 so that it can be focused. > Several of them do allow the dialog itself to be focused, though it's not > clear to me why. However, several of them do that by actually making an > ancestor focusable, not the dialog itself, and that's again what the > <dialog> spec does: the <body> ancestor is focusable, and the rest of the > document is inert. As I stated in a previous response: "If this focus notification comes in on the wrong element (body instead of dialog), the element ref and screen coordinates will be wrong, and the applications that rely on these details will not work as expected."
(In reply to Ian 'Hixie' Hickson from comment #19) > (In reply to James Craig from comment #18) > > > > Focus() not only moves document focus, it fires a system focus notification > > that is relied upon by keyboard users, zoom users, and screen reader users. > > Sure. showModal() should definitely do that. It would be dumb not to. It would dumb for the UA to send a focus notification when there was no change of focus, which is one reason we're saying the HTML spec should clearly define that focus is fired on an element inside the dialog, or failing that, the dialog itself. > But that's a UI issue. It is orthogonal to document.activeElement. ??? Not sure how to respond to this one. How are you suggesting that focus notifications should be decoupled from focus? > > If you’re displaying a form that is intended to be modal, it must get > > keyboard focus in order to work like a modal dialog on *any* platform that > > supports keyboard focus. > > There is no observable difference between the <dialog> element having focus > and the <body> element having focus, The entire thread is about all the observable differences between these two events. *You* may not be able to observe the difference, but that doesn't mean there is no observable difference. You're thinking too much like a sighted mouse user. > except that if we allowed the <dialog> > element to be focused, and you then nested them, it would mean you could > make an ancestor <dialog> have focus, which would be inconsistent with modal > dialogs on other platforms. If you're worried about nested dialogs, the spec could explicitly disallow them. That edge case seems unrelated to me, but for the sake of discussion: The ancestor dialog would be inert, and the descendant dialog would have focus, so I don't see your point. > I could see several arguments: > > - maybe we should find a way to make <dialog>s focusable, yet inert again > when > a descendant <dialog> is modal. This in particular might be helpful with > non- > modal <dialog>s since right now there's no way to focus them. > > - maybe we should focus the first control of a <dialog> if none are > marked with autofocus="", when a <dialog> is shown by showModal(). Seems like you came to a similar conclusion, but I'd go a couple steps further. See above > However neither of those have to do with ATs, which are already quite able > to do the right thing here, and neither of those things are what this bug is > ostensibly about. Again, this isn't strictly about ATs. It's about general usability and keyboard access in addition to ATs, and this pattern has been used for decades with platform APIs. HTML should match that behavior so every technology that relies on this pattern will continue to work as expected.
I'd say focus by default shouldn't be applied to not modal dialogs because dialogs of this kind can be used as simple popups to provide an additional info while the focus stays unchanged. Since modal dialogs prevent the user from accessing to underlying document until dismissed then the modal dialog must take the user focus. Thus I'd say the following steps should be applied: 1) focus the first focusable element in the dialog having autofocus attribute 2) otherwise focus first focusable element in the dialog 3) focus the dialog itself (the spec should make sure the dialog element is focusable similar to DOM document).
(In reply to alexander surkov from comment #24) > I'd say focus by default shouldn't be applied to not modal dialogs because > dialogs of this kind can be used as simple popups to provide an additional > info while the focus stays unchanged. Since modal dialogs prevent the user > from accessing to underlying document until dismissed then the modal dialog > must take the user focus. Thus I'd say the following steps should be applied: > > 1) focus the first focusable element in the dialog having autofocus attribute > 2) otherwise focus first focusable element in the dialog > 3) focus the dialog itself (the spec should make sure the dialog element is > focusable similar to DOM document). agreed, the requirement is specifically for modal dialogs.
(In reply to James Craig from comment #21) > > 1. So a keyboard user's focus is at the beginning of the dialog (e.g. > pressing tab will move to the first focusable node inside the dialog) That's the case as specced currently also (since focus will be either before or after the dialog, and thus the next thing in the ring is forcibly the first thing in the dialog, since nothing else in the doc is focusable at that point). > 2. So a system focus notification will fire, and like Zoom windows will move > to the right screen coordinates. showModal() can (and should) do that regardless. That's a UI issue. > 3. So screen readers will move their cursor (or "focus") into the dialog > based on the "focus changed" notification. showModal() can (and should) communicate to ATs directly about this. > You could propose a new "dialog opened" > accessibility notification in every platform API, but all of them are > currently expecting the browsers and apps to do this through standard focus > notifications, because they are useful for non-AT users, too. Every AT supports native dialogs already. I don't see why this would be special. (In reply to James Craig from comment #22) > > So it only moves to a control that has the autofocus attr set. I propose it > should: > > 1. Moves focus to the first element with the autofocus="" attribute. > 2. If #1 is not found, moves focus to the first focusable element. How would you handle the case of not wanting anything focused by default, e.g. the way that the "About this Mac" dialog on Mac doesn't initially have anything focused? > 3. If #2 is not found, moves focus to the dialog element itself which, if > not already focusable, temporarily assumes a tabIndex value of -1 so that it > can be focused. I don't understand why, as noted above. (Also, what does "temporarily" mean here?) > As I stated in a previous response: "If this focus notification comes in on > the wrong element (body instead of dialog), the element ref and screen > coordinates will be wrong, and the applications that rely on these details > will not work as expected." There's no focus notification at all in this case. Just a blur. showModal() should take care of all this. The spec shouldn't need to hand-hold UAs implementing good UIs, whether for ATs or otherwise. (In reply to James Craig from comment #23) > > Not sure how to respond to this one. How are you suggesting that focus > notifications should be decoupled from focus? I'm saying that how the AT behaves should have nothing to do with focus. Focus is about where the focus ring is and where key events go, and, if you have zoom-follows-focus, where zoom should go. When a new window opens, the focus might end up in a specific control, or nowhere at all, but that's orthogonal to the UA telling the AT telling the user about the whole window (or dialog) appearing. > If you're worried about nested dialogs, the spec could explicitly disallow > them. That edge case seems unrelated to me, but for the sake of discussion: > The ancestor dialog would be inert, and the descendant dialog would have > focus, so I don't see your point. If the dialog's ancestor is inert, so's the dialog. Inertness affects entire subtrees. > Again, this isn't strictly about ATs. It's about general usability and > keyboard access in addition to ATs, and this pattern has been used for > decades with platform APIs. HTML should match that behavior so every > technology that relies on this pattern will continue to work as expected. Other platforms don't actually make dialogs focusable. For example, try loading Mac's system preferences and giving focus to the dialog. You can't, either by mouse or by keyboard, even if you enable "full keyboard access". It acts exactly like HTML's currently specified <dialog> (all the way down to there sometimes not being anything focused, e.g. when you switch panes).
(In reply to Ian 'Hixie' Hickson from comment #26) > Other platforms don't actually make dialogs focusable. For example, try > loading Mac's system preferences and giving focus to the dialog. You can't, > either by mouse or by keyboard, even if you enable "full keyboard access". > It acts exactly like HTML's currently specified <dialog> (all the way down > to there sometimes not being anything focused, e.g. when you switch panes). incorrect open system preferences dialog using the keyboard focus is placed on the search box in the dialog use CTR+F7 to move to the buttons
> incorrect > open system preferences dialog using the keyboard > focus is placed on the search box in the dialog Please read what I wrote. I said the dialog. Yes, you can focus the controls _in_ the dialog (including the buttons if you enable that), but not the dialog itself. > use CTR+F7 to move to the buttons Tab/Shift+Tab is sufficient.
Created attachment 1402 [details] screenshot of a focused mac osx dialog
(In reply to steve faulkner from comment #29) > Created attachment 1402 [details] > screenshot of a focused mac osx dialog I am using UI browser which shows current focus. Current focus is on the dialog. In the properties list the focused attribute has a value of true so it would appear that the statement in comment 26 > Other platforms don't actually make dialogs focusable. is incorrect
Alex, James, Matt Is it reasonable to say we have consensus from implementers involved in this discussion that the following is what should be specced? 1) focus the first focusable element in the dialog having autofocus attribute 2) otherwise focus first focusable element in the dialog 3) focus the dialog itself (the spec should make sure the dialog element is focusable similar to DOM document).
Comment 29 shows an implementation detail; it's indistinguishable from what the HTML spec currently requires in the <dialog> case. The key aspect here is that it's not possible to manually focus the dialog. For example, hit Tab while that window is up, and then try to revert focus back to the window, with the mouse or keyboard. My point is that from an HTML perspective, it's not a focusable element.
(In reply to Ian 'Hixie' Hickson from comment #32) > Comment 29 shows an implementation detail; it's indistinguishable from what > the HTML spec currently requires in the <dialog> case. The key aspect here > is that it's not possible to manually focus the dialog. For example, hit Tab > while that window is up, and then try to revert focus back to the window, > with the mouse or keyboard. My point is that from an HTML perspective, it's > not a focusable element. ¿Que? Cmd + ` works fine for me, dialog gits focus.
(In reply to steve faulkner from comment #31) > Is it reasonable to say we have consensus from implementers involved[...] I can see how it's weird to make <dialog> focusable when other elements like <div> wouldn't be. At least, it's a magical property we shouldn't add unless necessary. Much of the disagreement in this thread seems to boil down to Hixie's comment that: "showModal() can (and should) communicate to ATs directly about [the newly opened dialog]". The a11y guys seem to think it's better to use focus to tell ATs about the dialog. Which is it? One thing that could make it more palatable to allow the active modal <dialog> to be focused is if we changed the spec to make ancestors of the <dialog> inert (and change the inertness definition so that your subtree is not inert). Then <dialog> being focusable is analogous to document.body being focusable. I'm not sure there is a good use case for non-inert ancestors of <dialog>. Some use cases are mentioned in https://www.w3.org/Bugs/Public/show_bug.cgi?id=22974#c4, but ::backdrop should cover them. (In reply to Ian 'Hixie' Hickson from comment #19) > There is no observable difference between the <dialog> element having focus > and the <body> element having focus, except[...] Another difference is <body> <div tabindex="1"> <div tabindex="1"> <div tabindex="1"> <dialog> Currently if <body> has focus you'd have to tab through the <div>s to get to the <dialog>.
(In reply to Matt Falkenhagen from comment #34) > (In reply to steve faulkner from comment #31) > > Is it reasonable to say we have consensus from implementers involved[...] > > I can see how it's weird to make <dialog> focusable when other elements > like <div> wouldn't be. At least, it's a magical property we > shouldn't add unless necessary. Why is it weird to make an element focusable that represents a UI element that is focusable in native implementations such as mac OSX or windows? <dialog> is not like a <div>. as it says in the spec: "The dialog element represents a part of an application that a user interacts with to perform a task, for example a dialog box, inspector, or window." it also says in the spec: "user agents may make any element or part of an element focusable, especially to aid with accessibility or to better match platform conventions." http://www.w3.org/html/wg/drafts/html/master/editing.html#focusable If it does not have the default behaviour of a dialog why require it to be mapped to a dialog role in acc APIs? > > Much of the disagreement in this thread seems to boil down to Hixie's > comment that: "showModal() can (and should) communicate to ATs > directly about [the newly opened dialog]". The a11y guys seem to think > it's better to use focus to tell ATs about the dialog. Which is it? Its not just ATs, this negatively effects keyboard users who do not use AT. see above the expected behaviour for a modal dialog is that it or one of its descendants gets focus, not an element outside of the dialog.
Created attachment 1404 [details] windows focusable modal dialog box have attached a graphic showing a standard windows modal dialog box: its acc properties indicate is is FOCUSABLE. when the dialog box is opened focus moves to the dialog box
(In reply to Matt Falkenhagen from comment #34) > I can see how it's weird to make <dialog> focusable when other elements > like <div> wouldn't be. At least, it's a magical property we > shouldn't add unless necessary. can you give an example please? > Much of the disagreement in this thread seems to boil down to Hixie's > comment that: "showModal() can (and should) communicate to ATs > directly about [the newly opened dialog]". The a11y guys seem to think > it's better to use focus to tell ATs about the dialog. Which is it? In either case AT communication will be focus since that's how AT and browsers works. That means if we don't make this HTML part then it will be a11y part or browser implementation detail. But in either case it doesn't seem like we have a total disagreement here. See Ian's comment #19. If those two 'maybe' parts are fulfilled then that's all we need (my comment #31).
(In reply to Ian 'Hixie' Hickson from comment #26) > > 2. So a system focus notification will fire, and like Zoom windows will move > > to the right screen coordinates. > > showModal() can (and should) do that regardless. That's a UI issue. It's not a UI issue. It's an API issue. > > 3. So screen readers will move their cursor (or "focus") into the dialog > > based on the "focus changed" notification. > > showModal() can (and should) communicate to ATs directly about this. As several of us have stated, this is not just about AT. > > You could propose a new "dialog opened" > > accessibility notification in every platform API, but all of them are > > currently expecting the browsers and apps to do this through standard focus > > notifications, because they are useful for non-AT users, too. > > Every AT supports native dialogs already. I don't see why this would be > special. Every AT supports dialogs because they fire proper focus notifications. > (In reply to James Craig from comment #22) > > > > So it only moves to a control that has the autofocus attr set. I propose it > > should: > > > > 1. Moves focus to the first element with the autofocus="" attribute. > > 2. If #1 is not found, moves focus to the first focusable element. > > How would you handle the case of not wanting anything focused by default, > e.g. the way that the "About this Mac" dialog on Mac doesn't initially have > anything focused? The "About this Mac" dialog actually fires two focus notifications: one on the window "Focused Window Changed" and one on the first image in the dialog "Focused Element Changed." The image does not show a focus outline, but it is focused via the API in order for keyboards, AT, and and other OS features to behave as expected. You appear to be confusing "nothing focused" with "nothing styled to look focused." The equivalent of this in HTML would be to focus() the dialog, or even a static element in the dialog, and have its tabindex set to -1, and CSS outline set to none. Hiding the visible focus outline is a UI issue. The rest is standard and necessary API. > > 3. If #2 is not found, moves focus to the dialog element itself which, if > > not already focusable, temporarily assumes a tabIndex value of -1 so that it > > can be focused. > > I don't understand why, as noted above. (Also, what does "temporarily" mean > here?) I would recommend, until it loses focus, at which point it could go back to it's defined tabindex value, e.g. undefined. > > As I stated in a previous response: "If this focus notification comes in on > > the wrong element (body instead of dialog), the element ref and screen > > coordinates will be wrong, and the applications that rely on these details > > will not work as expected." > > There's no focus notification at all in this case. Just a blur. showModal() > should take care of all this. The spec shouldn't need to hand-hold UAs > implementing good UIs, whether for ATs or otherwise. You're asking implementations to lie to applications, by firing focus notifications (in order to implement "good UI") where no focus has been set. You claim it's unnecessary, but your explanations make it clear that you don't understand how these technologies work. Engineers from multiple UA vendors are telling you you're wrong, and instead of reading the details listed here and accepting them, you keep repeating the same fallacies as if repetition will make them true.
(In reply to James Craig from comment #38) > > The "About this Mac" dialog actually fires two focus notifications: one on > the window "Focused Window Changed" and one on the first image in the dialog > "Focused Element Changed." The image does not show a focus outline, but it > is focused via the API in order for keyboards, AT, and and other OS features > to behave as expected. I think this is precisely the disconnect here. First, there's the difference between "focused window" and "focused control". They are unrelated concepts. :focus, HTMLElement.focus(), tabindex="", etc, work on focused controls, not focused windows. Now, if we want to make the <dialog> act like a focused window, that's something I could get behind. That, and the risk that authors will put tabindex="" on random ancestors of a <dialog>, could be a good argument for making inertness work on nodes rather than subtrees. It would still require explicit support in showModal() to inform ATs that there's a new focused window (and that it's not a native window), though (since HTML has no concept of "windows" in the DOM). Second, there's the issue of what it means for an element to be focused if there's no keyboard event handler, if tabbing and mouse clicks can't manually focus the control, if there's no focus ring, and if the element doesn't do anything in the first place. The implementation specifics are just that, implementation specifics. It doesn't matter that under the hood, an element is being marked as focused, if there's literally no way for the user to tell. There also doesn't have to be any correlation between what is focusable at the HTML level and what ATs let you move the AT cursor or magnification to (indeed, there better not be, since otherwise you couldn't read normal text and zoom on normal images, for example). > Engineers from multiple UA vendors are telling you you're wrong, and instead > of reading the details listed here and accepting them, you keep repeating > the same fallacies as if repetition will make them true. We are clearly speaking at cross-purposes, because I feel the same way in reverse. My point is that just because some implementations happen to have one implementation strategy under the hood, it doesn't mean that's the way all UAs should do it, and it doesn't mean it's what we should spec. What matters is what is user-detectable, and how this maps to UA requirements. We specifically don't give precise interface requirements because doing so doesn't help interop but constrains implementations. This is true whether the UI is the mainstream UI or an AT UI or something else. (This, IMHO, is one of the failings of ARIA. Instead of being designed to enable sites to improve their accessibility story while allowing UAs and ATs to continue to innovate, it tied them so tightly together that we're not discussing specific user-invisible implementation details as interoperability issues.)
(In reply to Ian 'Hixie' Hickson from comment #39) now I am getting confused as to what your argument is, previously you have claimed that native implementations of dialog do not get keyboard focus, a claim that is bogus and been shown to be so. Now you appear to be saying we don't need to follow platform conventions, because somehow your proposal is superior. You have not provided any reasons why your proposed behaviour is superior, can you provide them? While we have provided arguments as to the benefits to a range of users for making dialogs focusable.
Created attachment 1405 [details] mac osx dialog without focus this is an example of a mac osx dialog that is visible but not currently focused
Created attachment 1406 [details] mac osx dialog with focus this is an example of a mac osx dialog with focus, it is visibly different from an unfocused dialog, because it has focus its title bar is coloured differently, the dialog itself has a drop shadow. It can also be dismissed using the keyboard by pressing the esc key (no AT in sight), when it is not focused it cannot be dismissed.
(In reply to Ian 'Hixie' Hickson from comment #39) > (In reply to James Craig from comment #38) > > > > The "About this Mac" dialog actually fires two focus notifications: one on > > the window "Focused Window Changed" and one on the first image in the dialog > > "Focused Element Changed." The image does not show a focus outline, but it > > is focused via the API in order for keyboards, AT, and and other OS features > > to behave as expected. > > I think this is precisely the disconnect here. > > First, there's the difference between "focused window" and "focused > control". They are unrelated concepts. :focus, HTMLElement.focus(), > tabindex="", etc, work on focused controls, not focused windows. <dialog> is an element, not a window, and :focus, HTMLElement.focus(), tabindex="", etc, work on focused *elements*, including <dialog> > Now, if we want to make the <dialog> act like a focused window, that's > something I could get behind. Unless you want to turn the dialog *element* into an actual native *window* (e.g. capable of being displayed outside the current web view similar to a frame) then this suggestion is inappropriate. The > That, and the risk that authors will put > tabindex="" on random ancestors of a <dialog>, could be a good argument for > making inertness work on nodes rather than subtrees. It would still require > explicit support in showModal() to inform ATs that there's a new focused > window (and that it's not a native window), though (since HTML has no > concept of "windows" in the DOM). Precisely, it's not a native window, but even if the HTML spec were updated to have <dialog> behave like a pseudo-window, APIs would still expect the "focused window" to have a "focused element." Your suggestion is to have APIs claim the <dialog> element is a "focused window" but the "focused element is an ancestor body element. This is a misuse of the notifications and effectively "lying" to the APIs and applications. It can't be the focused window if keyboard focus is elsewhere. > Second, there's the issue of what it means for an element to be focused if > there's no keyboard event handler, if tabbing and mouse clicks can't > manually focus the control, if there's no focus ring, and if the element > doesn't do anything in the first place. The implementation specifics are > just that, implementation specifics. It doesn't matter that under the hood, > an element is being marked as focused, if there's literally no way for the > user to tell. You're still thinking like a sighted mouse user with browser defaults. Your statement would only be accurate if you changed it to, "...there's literally no way for the [sighted mouse] user to tell [as long as they also didn't have a custom user custom style sheet]." > There also doesn't have to be any correlation between what is > focusable at the HTML level and what ATs let you move the AT cursor or > magnification to (indeed, there better not be, since otherwise you couldn't > read normal text and zoom on normal images, for example). No one is claiming that elements have to be focusable in order for AT to move to them. We are claiming new dialogs must be focused in order for a keyboard focus notification to be sent, which is the proper way to inform a platform API that the user's point of regard or focus context should be transferred to the new element. > > Engineers from multiple UA vendors are telling you you're wrong, and instead > > of reading the details listed here and accepting them, you keep repeating > > the same fallacies as if repetition will make them true. > > We are clearly speaking at cross-purposes, because I feel the same way in > reverse. > > My point is that just because some implementations happen to have one > implementation strategy under the hood, it doesn't mean that's the way all > UAs should do it, and it doesn't mean it's what we should spec. What matters > is what is user-detectable, and how this maps to UA requirements. We > specifically don't give precise interface requirements because doing so > doesn't help interop but constrains implementations. Clearly Steve, Alex, and I agree that using a standard focus notification here would help interoperability. I hope we can convince you of that as well. We also don't agree that this constrains implementations. For example, on mobile platforms where there is a limited concept of keyboard focus, this would not need to set a focus ring, but it would still be useful to have a consistent value for document.activeElement. Likewise, on systems that do have keyboard focus, an AT is not required to *heed* any or all focus notifications. As another UI example, most screen readers have a mode where they completely ignored focus, but then they don't work as well when things like newly focused dialogs pop up. > This is true whether > the UI is the mainstream UI or an AT UI or something else. (This, IMHO, is > one of the failings of ARIA. Instead of being designed to enable sites to > improve their accessibility story while allowing UAs and ATs to continue to > innovate, it tied them so tightly together that we're not discussing > specific user-invisible implementation details as interoperability issues.) Not sure which part of ARIA you're referring to. If you're talking about the de facto keypress combinations recommended in the authoring practices guide (not the spec), then I agree with you, and it's we removed those from the spec, and it's what we're hoping to solve more effectively with IndieUI.
We're still talking at cross-purposes here. Suppose you have a dialog box in a native app, and that dialog box has two text fields in it. You can focus the text fields. When you focus one, the other loses focus. When you focus the other, the first loses focus. Orthogonally to this, you can focus the dialog, or you can move focus to another window entirely. The dialog and the text fields can have focus simultaneously. These are different notions of focus. One is focus at a control level, the other is focus at the window level. Moving focus amongst controls is typically done with Tab/Shift+Tab, or clicking on the control. Moving focus amongst windows is typically done with application-switching controls like Command-Tilde/Command-Tab on Mac, or clicking on the dock, or picking a window from the Window menu, etc. Now, in HTML, we have the same thing. There's focus at the control level: document.activeElement, element.focus(), :focus, tabindex="", etc. And then there's focus at the window level, which until now has only been possible at the Window object level. With <dialog>, we make it possible to focus windows. The open="" attribute makes a <dialog> visible; dialog.show() can make it have focus as well. showModal() makes a <dialog> visible and have focus and makes it modal. None of this is exposed in the control-level focus APIs, because they aren't controls, they're windows. (That they're not native windows is neither here nor there from the user's perspective). I'm happy to consider what we should do in terms of exposing this concept of window focus more explicitly, but we can't start mixing control focus and window focus. That will lead to wacked out UIs that are inconsistent with all existing platforms, and will confuse users no end.
So it sounds like we deal here with two problems which can be splitted into two separate bugs: 1) If @autofocus attribute is omitted then first focusable control is supposed to take the focus. While it should be nice but that may be considered optional. 2) If no focused control (@autofocus or otherwise) then spec should say clearly the dialog (as a window) is focused or active or whatever terminology is used
(In reply to Ian 'Hixie' Hickson from comment #44) > We're still talking at cross-purposes here. > > Suppose you have a dialog box in a native app, and that dialog box has two > text fields in it. > > You can focus the text fields. When you focus one, the other loses focus. > When you focus the other, the first loses focus. > > Orthogonally to this, you can focus the dialog, or you can move focus to > another window entirely. The dialog and the text fields can have focus > simultaneously. These are different notions of focus. One is focus at a > control level, the other is focus at the window level. > > Moving focus amongst controls is typically done with Tab/Shift+Tab, or > clicking on the control. Moving focus amongst windows is typically done with > application-switching controls like Command-Tilde/Command-Tab on Mac, or > clicking on the dock, or picking a window from the Window menu, etc. > > Now, in HTML, we have the same thing. There's focus at the control level: > document.activeElement, element.focus(), :focus, tabindex="", etc. And then > there's focus at the window level, which until now has only been possible at > the Window object level. With <dialog>, we make it possible to focus > windows. The open="" attribute makes a <dialog> visible; dialog.show() can > make it have focus as well. showModal() makes a <dialog> visible and have > focus and makes it modal. None of this is exposed in the control-level focus > APIs, because they aren't controls, they're windows. (That they're not > native windows is neither here nor there from the user's perspective). Yes I agree that HTML's concept of focus management leaves much to be desired. That is a much larger problem, however, than the one we're trying to solve here. > I'm happy to consider what we should do in terms of exposing this concept of > window focus more explicitly, but we can't start mixing control focus and > window focus. That will lead to wacked out UIs that are inconsistent with > all existing platforms, and will confuse users no end. We're not mixing focus between these two types. Each element's default role conveys enough context to differentiate between these types.
If we use exclusively the mechanism used for controls, then when you focus a text field in a <dialog>, the <dialog> loses focus. That doesn't make sense. We should solve the much larger problem. Even if a control with autofocus="" gets focused, the dialog still needs to be focused. These are just completely orthogonal. So far, here are the issues I think have been raised: - showModal() should prevent ancestor elements with tabindex="" from getting focused: That makes sense. Filed bug 23456. - no autofocus="" should mean that the first element should be focused: I disagree, because that leaves no way for no control to be focused by default. - the <dialog> should be focused in the sense of it being the activeElement: That makes no sense to me, as discussed above. - there should be clearer text on how a <dialog> can be focused, how show() and showModal() affect this, etc: I'll do that as part of this bug. Is there anything else?
Changed title back to "modify focus steps to move focus to dialog by default", please clone for your related issue about a separate concept of window focus. It seems like you're still ignoring the issue that all platform APIs expect move focus to an element inside the dialog, whether it's the dialog or not. The HTML spec only does this when autofocus is explicitly set on one of the elements inside the dialog. If we can't agree on the dialog fallback, perhaps we can compromise on some intermediary heuristics. How about this: When a dialog is opened, UAs MUST move focus to: 1. The first focusable element matching [autofocus] in the dialog, or 2. The first focusable element in the dialog... Can we agree on that much at least? If not, why not? Once we get to that point of compromise, I'd argue there need to be more steps, for example: or... 3. The first heading in the dialog, or... 4. The first text element (or image element including alternative text) in the dialog. UAs MAY hide focus outline of implicitly focused non-interactive text or image elements. (Treat these equivalent to tabindex="-1" and CSS outline:none1;) The last step of this heuristic (focusing the dialog) seems to be where most of the disagreement lies, so I can agree to discuss that in a cloned issue about "window focus" if this bug can remain about the problem that dialogs currently don't get *any* focus unless an HTML author explicitly includes autofocus.
(In reply to James Craig from comment #48) > When a dialog is opened, UAs MUST move focus to: > > 1. The first focusable element matching [autofocus] in the dialog, or > 2. The first focusable element in the dialog... > > Can we agree on that much at least? If not, why not? It must be covered by this bug discussions so sorry for asking you to repeat the things but few questions to make things clearer with me. Could you please outline bad things (both from AT and keyboard user perspective) if no focusable is focused in the modal dialog (the case when the dialog itself gets focused)? > Once we get to that point of compromise, I'd argue there need to be more > steps, for example: > > or... > 3. The first heading in the dialog, or... > 4. The first text element (or image element including alternative text) in > the dialog. how is it supposed to work if they aren't focusable?
(In reply to Ian 'Hixie' Hickson from comment #47) > - no autofocus="" should mean that the first element should be focused: I disagree, because that leaves no way for no control to be focused by default. whats the use case for no control receiving focus? > - the <dialog> should be focused in the sense of it being the activeElement: That makes no sense to me, as discussed above. why does having the <body> be the activeElement make sense?
> It seems like you're still ignoring the issue that all platform APIs expect > move focus to an element inside the dialog, whether it's the dialog or not. I'm not ignoring it, I'm saying it's false. There are dialogs, e.g. the About This Mac dialog, where nothing is focused. (Under the hood, as mentioned in earlier comments, the image is focused or some such. But that's just a hack, the image being focused is indistinguishable, for the user, from nothing being focused.) More generally, when you open a Web page, nothing is focused by default. I don't understand why <dialog> is different from a Web page here. Why is it that opening a Web page shouldn't focus anything in particular, but opening a dialog should focus a control? > When a dialog is opened, UAs MUST move focus to: > > 1. The first focusable element matching [autofocus] in the dialog, or > 2. The first focusable element in the dialog... > > Can we agree on that much at least? If not, why not? I think that'd be great, except that it means we don't handle the use case of dialogs that have no focused element. But maybe we just don't care about that use case. If there's no focusable element, do you agree that nothing should be focused? > Once we get to that point of compromise, I'd argue there need to be more > steps, for example: > > or... > 3. The first heading in the dialog, or... > 4. The first text element (or image element including alternative text) in > the dialog. Those aren't focusable in the first place. I don't understand what it would even mean for us to focus them. Note that focus has nothing to do with the AT speaking back the dialog, or whatnot. That should happen regardless. > UAs MAY hide focus outline of implicitly focused non-interactive text or > image elements. (Treat these equivalent to tabindex="-1" and CSS > outline:none;) tabindex=-1 doesn't mean "can't be focused". You can still focus one of those things with the mouse. And then key events go to them. I really don't understand why there is a difference here between how you want <dialog>s to work and how you want documents to work.
(In reply to Ian 'Hixie' Hickson from comment #51) > > It seems like you're still ignoring the issue that all platform APIs expect > > move focus to an element inside the dialog, whether it's the dialog or not. > > I'm not ignoring it, I'm saying it's false. There are dialogs, e.g. the > About This Mac dialog, where nothing is focused. (Under the hood, as > mentioned in earlier comments, the image is focused or some such. But that's > just a hack, the image being focused is indistinguishable, for the user, > from nothing being focused.) So... if you agree with the facts, it's truth. If you don't agree with the facts, it's "just a hack" and of no benefit. > More generally, when you open a Web page, > nothing is focused by default. I don't understand why <dialog> is different > from a Web page here. Why is it that opening a Web page shouldn't focus > anything in particular, but opening a dialog should focus a control? Wrong again. When a document opens, the body element is focused (check document.activeElement). We are asking nothing more than than consistent behavior for dialogs. > > When a dialog is opened, UAs MUST move focus to: > > > > 1. The first focusable element matching [autofocus] in the dialog, or > > 2. The first focusable element in the dialog... > > > > Can we agree on that much at least? If not, why not? > > I think that'd be great, except that it means we don't handle the use case > of dialogs that have no focused element. > > But maybe we just don't care about that use case. > > If there's no focusable element, do you agree that nothing should be focused? Why even post this question when the next line answers it? > > Once we get to that point of compromise, I'd argue there need to be more > > steps, for example: > > > > or... > > 3. The first heading in the dialog, or... > > 4. The first text element (or image element including alternative text) in > > the dialog. > > Those aren't focusable in the first place. I don't understand what it would > even mean for us to focus them. > > Note that focus has nothing to do with the AT speaking back the dialog, or > whatnot. That should happen regardless. Once again, your statement is completely false. It may not be the way you want it to be, but that doesn't mean it's not true. > > UAs MAY hide focus outline of implicitly focused non-interactive text or > > image elements. (Treat these equivalent to tabindex="-1" and CSS > > outline:none;) > > tabindex=-1 doesn't mean "can't be focused". You can still focus one of > those things with the mouse. And then key events go to them. You're fond of claiming that these focusing the dialog or a non-interactive element inside the dialog is indistinguishable by users (sighted, mouse users anyway). We've repeatedly proven you're wrong, but if you really do believe that focusing these elements is indistinguishable to a user, then why do you care if one of these elements gets focused? Keyboard access gets to work as it normally would because the dialog element uses standard focus behavior, and sighted mouse users are none the wiser. Perhaps I can sell you on a technical reason. If the dialog element (or a descendant element in the dialog) is focused, then key event target is also in the dialog, so standard dismiss key handlers (e.g. Escape key) can be contextually. This may not be strictly necessary for the dialog API, but it's just one of many reasons why native dialogs already get keyboard focus by default.
(In reply to James Craig from comment #52) Plenty of typos in my response. Just correcting the one that was not obvious: > Perhaps I can sell you on a technical reason. If the dialog element (or a > descendant element in the dialog) is focused, then key event target is also > in the dialog, so standard dismiss key handlers (e.g. Escape key) can be > contextually. This may not be strictly necessary for the dialog API, but > it's just one of many reasons why native dialogs already get keyboard focus > by default. ...so standard dismiss key handlers (e.g. Esc) can be *handled* contextually.
(In reply to alexander surkov from comment #49) > (In reply to James Craig from comment #48) > > > When a dialog is opened, UAs MUST move focus to: > > > > 1. The first focusable element matching [autofocus] in the dialog, or > > 2. The first focusable element in the dialog... > > > > Can we agree on that much at least? If not, why not? > > It must be covered by this bug discussions so sorry for asking you to repeat > the things but few questions to make things clearer with me. > > Could you please outline bad things (both from AT and keyboard user > perspective) if no focusable is focused in the modal dialog (the case when > the dialog itself gets focused)? Keyboard focus doesn't move into the dialog so: 1. Screen readers that follow focus (most) will not be alerted that the user's context should be moved into the dialog. 2. Screen magnifiers (Zoom) that follow focus will not move to the screen coordinates of the dialog. 3. Keyboard events initiated while the dialog is showing will be targeted to the body element instead of to the dialog (or a descendant of the dialog), so event delegation would need to use other heuristics to to figure out the context of the user's intention. 4. Keyboard focus will be at the start of the body element rather than at the start of the dialog, so sequential Tab key presses may not land on the expected elements. Note: Ian claims this won't be a problem since the rest of the document is inert, but I'm not convinced there will never be a case where the dialog will be the only focusable element in the document. There are probably more. > > Once we get to that point of compromise, I'd argue there need to be more > > steps, for example: > > > > or... > > 3. The first heading in the dialog, or... > > 4. The first text element (or image element including alternative text) in > > the dialog. > > how is it supposed to work if they aren't focusable? The next line was intended to answer that: > > UAs MAY hide focus outline of implicitly focused non-interactive text or > > image elements. (Treat these equivalent to tabindex="-1" and CSS outline:none;)
activeElement returns the body element _when no element is focused_. The body element isn't (unless it has a tabindex="" attribute set) focusable. > > Note that focus has nothing to do with the AT speaking back the dialog, or > > whatnot. That should happen regardless. > > Once again, your statement is completely false. It may not be the way you > want it to be, but that doesn't mean it's not true. I don't know how to reconcile that with the behaviour of every AT I've ever used. Take Voice Over for example. Open this page with VO enabled: http://junkyard.damowmow.com/524 Notice how it reads the whole page, showing a VO focus box around each part of the text as it reads it, first the heading, then the first sentence, and so on. Notice in particular what happens when it gets to the link: _It focuses the link_. The link _remains focused as the VO focus continues down the page_. Now press VO+Home. Notice how the VO focus moves to the top of the document again, leaving the HTML focus on the link. Press VO+A. Notice how it reads the entire page, without moving the HTML focus. Now consider a <dialog>. There's no reason, that I can see, that the <dialog> needs to have HTML focus for it to be read. Indeed, imagine if the page above was wrapped in a <dialog> and the first thing that happened when the page was opened was that the dialog's showModal() was called. Where should the VO focus start? It should start at the top of the dialog. Where should the HTML focus be? If it's anywhere, it should be on the link. You can see this if you look at what happens when you invoke an alert() with VoiceOver enabled. The keyboard/system focus is the button straight away, as it should be so that the user can immediately dismiss the alert. VoiceOver, however, reads the whole alert, and the VO focus actually remains at the top of the dialog. Now, when you call show() or showModal(), then I completely agree that the VO focus should be moved to the <dialog> and it should start reading the dialog. But my point has been, and remains, that this is orthogonal to where the keyboard focus (the per-element focus currently described in HTML) is. > You're fond of claiming that these focusing the dialog or a non-interactive > element inside the dialog is indistinguishable by users (sighted, mouse > users anyway). Any users. The keyboard focus being on something that isn't manually mouse or keyboard focusable, that is not interactive, has no focus ring, and doesn't react to key events is indistinguishable, to any user, as nothing having keyboard focus. This is orthogonal to window focus and AT focus. (I guess it might be distinguishable to users with magnification-follows-keyboard-focus enabled. I couldn't get that to work at all on my Mac. But in the case where the user has this enabled, and there's no element focused, there's no reason the UA or the AT can't move the magnification to the element with "window focus", just like the canvas APIs that move the magnification manually.) > but if you really do believe that focusing these elements is indistinguishable > to a user, then why do you care if one of these elements gets focused? Because it's not indistinguishable to authors. It screws up where keyboard events go; it breaks the invariant that non-focusable elements can't get focus. > Perhaps I can sell you on a technical reason. If the dialog element (or a > descendant element in the dialog) is focused, then key event target is also > in the dialog, so standard dismiss key handlers (e.g. Escape key) can be > contextually. This may not be strictly necessary for the dialog API, but > it's just one of many reasons why native dialogs already get keyboard focus > by default. I think it would make sense that if no focusable element is focused, the key events should go to the element with "window focus", when we add that concept. But that's orthogonal to the concept of element focus in the spec now.
(In reply to Ian 'Hixie' Hickson from comment #55) > activeElement returns the body element _when no element is focused_. The > body element isn't (unless it has a tabindex="" attribute set) focusable. This is indistinguishable from the body element having tabindex="-1" and CSS outline:0; > > > Note that focus has nothing to do with the AT speaking back the dialog, or > > > whatnot. That should happen regardless. > > > > Once again, your statement is completely false. It may not be the way you > > want it to be, but that doesn't mean it's not true. > > I don't know how to reconcile that with the behaviour of every AT I've ever > used. Take Voice Over for example. I'm aware of how VoiceOver works. As I mentioned in comment #43, no one is claiming that elements have to be focusable in order for assistive technologies to move to them. We are claiming new dialogs must be focused in order for a keyboard focus notification to be sent, which is the proper way to inform a platform API that the user's point of regard or focus context should be transferred to the new element. For example, compare the behavior of these two test pages by turning on a screen reader, tabbing to the "Check Out" button, and pressing spacebar or the screen reader's activation key (e.g. VO+Space in VoiceOver) http://cookiecrook.com/test/aria/HandsOn/6_HandsOn_AriaAdvanced/inaccessible/inaccessible.htm http://cookiecrook.com/test/aria/HandsOn/6_HandsOn_AriaAdvanced/accessible/accessible.htm In the inaccessible version, no focus event is fired, so the screen reader stays where it is. In the accessible version, an element inside the dialog is focused. Because of this focus notification, the screen reader runs up the ancestor chain and sees that the focus is now in a dialog, and therefore announces it. I know you've claimed that focus here is "completely orthogonal" or "just a hack" but it's how these technologies expect to work together. You have personally claimed that one of the goals of HTML 5 is first to document what browsers (and OSes) actually do, before making up new APIs that no one has expressed interest in adopting. Why does this goal change for you when it's related to full keyboard access or accessibility APIs? > Now, when you call show() or showModal(), then I completely agree that the > VO focus should be moved to the <dialog> and it should start reading the > dialog. I understand that it's technically possible to rewrite every user agent, containing browser, assistive technology, and operating system to use a new set of events that you're spitballing. However, I see no benefits to proposing this, when focus notifications are how they expect to work today. Even if everyone agreed that were a better approach, it should not sacrifice interoperability with today's APIs. > But my point has been, and remains, that this is orthogonal to where > the keyboard focus (the per-element focus currently described in HTML) is. These are not orthogonal concepts. They are documented APIs that are directly tied to focus events. For example: MSAA: EVENT_OBJECT_FOCUS Microsoft UIA: UIA_AutomationFocusChangedEventId ATK/AT-SPI: object:state-changed:focused AX API: AXFocusedUIElementChanged > > but if you really do believe that focusing these elements is indistinguishable > > to a user, then why do you care if one of these elements gets focused? > > Because it's not indistinguishable to authors. It screws up where keyboard > events go; It puts keyboard event targets exactly where they need to be. On the only non-inert thing in the document, which can still bubble up to the inert body element if needed for event delegation. > [and] it breaks the invariant that non-focusable elements can't get focus. Any element can get focused. It's not the same as getting into the tab order. > > Perhaps I can sell you on a technical reason. If the dialog element (or a > > descendant element in the dialog) is focused, then key event target is also > > in the dialog, so standard dismiss key handlers (e.g. Escape key) can be > > contextually. This may not be strictly necessary for the dialog API, but > > it's just one of many reasons why native dialogs already get keyboard focus > > by default. > > I think it would make sense that if no focusable element is focused, the key > events should go to the element with "window focus", when we add that > concept. But that's orthogonal to the concept of element focus in the spec > now. Not orthogonal. This is exactly what happens with the body element. document.activeElement returns the body element in a window and the body is "focused" just not visibly so. The same behavior should apply to dialogs, because it doesn't make sense to have the inert body element be the focused activeElement.
(In reply to Ian 'Hixie' Hickson from comment #55) Another data point: 1. navigate to the help menu in firefox (using keyboard). activate the 'about firefox' menu item. 2. a dialog is opened, focus moves to the dialog (it has a state of focusable, focused), pressing the tab key moves focus to the first focusable child of the dialog. see associated screenshot. I suggest that the fact that in your proposed definition of <dialog> it is not a focusable element is a bug not a feature.
Created attachment 1408 [details] screenshot of a focused dialog The screenshot shows a firefox dialog that is focusable and has focus. the focus is highlighted and the state is exposed using an object inspection tool. see comment 57 for steps to reproduce
(In reply to steve faulkner from comment #58) > Created attachment 1408 [details] > screenshot of a focused dialog > > The screenshot shows a firefox dialog that is focusable and has focus. the > focus is highlighted and the state is exposed using an object inspection > tool. > > see comment 57 for steps to reproduce Unless I'm missing something, it seems to me that focusing the dialog (container) itself is necessary so users do not miss content within the dialog. By focusing _it_ you allow users to tab to the first of its controls, so nothing is skipped over. Say there are two buttons in the dialog, CONFIRM and CANCEL. If we were to focus the first of these when the dialog is open and if the content of the dialog _above_ the buttons is being announced like an alert, hitting tab to skip to the controls would actually mean moving focus from the first button to the second, effectively obscuring the CONFIRM button. CANCEL would seem like the only available action (?)
I don't understand why you think there's only one kind of focus here. I can distinguish at least three kinds of focus, the AT's current position, the keyboard focus, the window focus. They are related, but orthogonal, as easily demonstrated by all the examples that all of us have been showing. I really don't understand why we're not seeing the same thing here. (In reply to heydon from comment #59) > > Unless I'm missing something, it seems to me that focusing the dialog > (container) itself is necessary so users do not miss content within the > dialog. Yes, the window and AT focus needs to move to the dialog, and the AT focus needs to start moving through the dialog reading it; however, the keyboard focus starts on the first focusable control. > Say there are two buttons in the dialog, CONFIRM and CANCEL. If we were to > focus the first of these when the dialog is open and if the content of the > dialog _above_ the buttons is being announced like an alert, hitting tab to > skip to the controls would actually mean moving focus from the first button > to the second, effectively obscuring the CONFIRM button. CANCEL would seem > like the only available action (?) Try it. Make sure you have full keyboard focus enabled ("All controls" in Mac, for instance; I think it's the default on Windows), and enable a screen reader, e.g. VoiceOver, then call window.confirm(), which pops up a dialog with text and two buttons. The window focus moves to the dialog, the AT focus moves to the top of the dialog and starts walking down it, and the keyboard focus jumps to the first button. All of this happens as soon as the dialog appears. (In reply to James Craig from comment #56) > (In reply to Ian 'Hixie' Hickson from comment #55) > > activeElement returns the body element _when no element is focused_. The > > body element isn't (unless it has a tabindex="" attribute set) focusable. > > This is indistinguishable from the body element having tabindex="-1" and CSS > outline:0; There are several ways to distinguish it. One is that without tabindex="", when you focus an element, the <body> doesn't get a blur event, and when you unfocus another element by clicking on the page's background, the body doesn't get a focus event. When you focus another window or browsing context, though, the Window gets a blur event. With tabindex="", the <body> element acts just like another focusable element, getting blur and focus events and so on. You can put it in the tab order, focus it with the mouse, etc. > > I don't know how to reconcile that with the behaviour of every AT I've ever > > used. Take Voice Over for example. > > I'm aware of how VoiceOver works. As I mentioned in comment #43, no one is > claiming that elements have to be focusable in order for assistive > technologies to move to them. We are claiming new dialogs must be focused in > order for a keyboard focus notification to be sent, which is the proper way > to inform a platform API that the user's point of regard or focus context > should be transferred to the new element. If it's the proper way, why is it not how prompt() works? (It focuses a button, but the dialog is read from the top when it comes up.) > For example, compare the behavior of these two test pages by turning on a > screen reader, tabbing to the "Check Out" button, and pressing spacebar or > the screen reader's activation key (e.g. VO+Space in VoiceOver) > > In the inaccessible version, no focus event is fired, so the screen reader > stays where it is. In the accessible version, an element inside the dialog > is focused. Because of this focus notification, the screen reader runs up > the ancestor chain and sees that the focus is now in a dialog, and therefore > announces it. I'm not objecting to focus going to a focusable control... nothing in this example seems to focus the dialog, though, which is what I'm saying doesn't make sense. What I'm saying is that we can make the <dialog> act just like the root <body> does when there's no dialog up (e.g. receiving key events if nothing is focused), but it shouldn't receive 'focus' and 'blur' events and be in the tab order and be mouse-focusable and so on. It should be able to get window focus, but that's not element focus. > > [and] it breaks the invariant that non-focusable elements can't get focus. > > Any element can get focused. It's not the same as getting into the tab > order. Any element can get the AT focus, but it's not the case that any element can get into document.activeElement, can receive focus/blur events, etc. The focus() method's algorithm's first step does nothing if the element is not focusable. If you call focus() on a <body> element, nothing happens (unless it happens to have a tabindex="" attribute). > Not orthogonal. This is exactly what happens with the body element. > document.activeElement returns the body element in a window and the body is > "focused" just not visibly so. The same behavior should apply to dialogs, > because it doesn't make sense to have the inert body element be the focused > activeElement. I'm happy to spec the same thing for <dialog> as for <body> (your arguments and examples make a compelling case that we should do that). However, that's not what you're describing. If you think I'm wrong, educate me. Why am I seeing the behaviour I describe in comment 55 for the test case mentioned there? How do you explain how the VO focus doesn't follow the keyboard focus on that test? How do you explain that pages get focused even though no 'focus' events fire? How do you explain that the confirm() dialog's text gets read out even though a button _after_ the text is focused and remains focused the entire time?
(In reply to Ian 'Hixie' Hickson from comment #60) > I don't understand why you think there's only one kind of focus here. I can > distinguish at least three kinds of focus, the AT's current position, the > keyboard focus, the window focus. They are related, but orthogonal, as > easily demonstrated by all the examples that all of us have been showing. I > really don't understand why we're not seeing the same thing here. The term "focus" means one thing on OS X: keyboard focus. The thing you're referring to as "window focus" is actually called the "key window" (Look up Cocoa's concept of a "first responder chain"). The black-bordered "VoiceOver cursor" is not tied to keyboard focus, but by default it both follows keyboard focus (e.g. when focus notifications fire, VO lands on same item) and it pulls keyboard focus along with it (e.g. when VO cursor lands on a focusable item, it sets the keyboard focus programmatically to match where the VO cursor is).
(In reply to Ian 'Hixie' Hickson from comment #60) > (In reply to James Craig from comment #56) > > (In reply to Ian 'Hixie' Hickson from comment #55) > > > I don't know how to reconcile that with the behaviour of every AT I've ever > > > used. Take Voice Over for example. > > > > I'm aware of how VoiceOver works. As I mentioned in comment #43, no one is > > claiming that elements have to be focusable in order for assistive > > technologies to move to them. We are claiming new dialogs must be focused in > > order for a keyboard focus notification to be sent, which is the proper way > > to inform a platform API that the user's point of regard or focus context > > should be transferred to the new element. > > If it's the proper way, why is it not how prompt() works? (It focuses a > button, but the dialog is read from the top when it comes up.) AppKit-based dialogs and sheets have consistent keyboard behavior, where the Return key always activates the default button, Escape key always activates the Cancel button (if there is one), and Spacebar always activate the focused button. Because the UI for these dialogs is always identical, and keyboard behavior is 100% predictable, VoiceOver does not need to move to the focused element, but the focus notification is what alerts VoiceOver that keyboard focus has moved into the dialog, and the rest of VO's behavior is UI differentiation. With ARIA based dialogs, like the accessible demo linked in Comment #56, VoiceOver focus follows remains on the keyboard focused element, primarily due to the fact that web dialogs are vended by any number of frameworks and therefore completely inconsistent. The reason screen readers still speak the dialog is thus: 1. Focus notification fired on an element within the dialog, or the dialog itself. 2. Screen readers walk up the ancestor chain, starting with the focused element. 3. Once it finds the dialog, it looks for the label (provided by aria-label or aria-labelledby) and description (provided by aria-describedby). 4. When the screen reader has all these pieces, it can present the data to the user however it wants. Again, UI differentiation. > > For example, compare the behavior of these two test pages by turning on a > > screen reader, tabbing to the "Check Out" button, and pressing spacebar or > > the screen reader's activation key (e.g. VO+Space in VoiceOver) > > > > In the inaccessible version, no focus event is fired, so the screen reader > > stays where it is. In the accessible version, an element inside the dialog > > is focused. Because of this focus notification, the screen reader runs up > > the ancestor chain and sees that the focus is now in a dialog, and therefore > > announces it. > > I'm not objecting to focus going to a focusable control... nothing in this > example seems to focus the dialog, though, which is what I'm saying doesn't > make sense. What I'm saying is that we can make the <dialog> act just like > the root <body> does when there's no dialog up (e.g. receiving key events if > nothing is focused), but it shouldn't receive 'focus' and 'blur' events and > be in the tab order and be mouse-focusable and so on. It should be able to > get window focus, but that's not element focus. The part that you're missing is that key windows always have a focused element. I pointed this out in the "About" dialog you mentioned, but you called it a hack. Our argument and this whole bug is about consistent heuristics for HTML to determine what the focused element in a dialog should be, which was more or less: 1. The autofocused element, or 2. The first focusable element, or 3. The dialog's label (e.g. a heading), or 4. The first element containing text or a text alternative, or 5. The dialog itself of none of these others exist. > > > [and] it breaks the invariant that non-focusable elements can't get focus. > > > > Any element can get focused. It's not the same as getting into the tab > > order. > > Any element can get the AT focus, but it's not the case that any element can > get into document.activeElement, can receive focus/blur events, etc. The > focus() method's algorithm's first step does nothing if the element is not > focusable. If you call focus() on a <body> element, nothing happens (unless > it happens to have a tabindex="" attribute). Let me clarify, any element can get focused. Some need a tabindex attribute. Some don't. Perhaps you're hung up on the behavior of tabindex="-1" which is currently the closest to what we want here, but as you've pointed out, the body element's focusability behavior is not identical to the behavior induced by tabindex="-1". Perhaps what you could spec is a new behavior for the value of tabindex="-2" which could be the default for <body> and <dialog>. The primary benefit is that it would be backwards compatible with today's behavior for tabindex, so focus notifications would work with today's APIs while they're being updated to match the idea you're spitballing of separate types of dialog focus, and element focus. > > Not orthogonal. This is exactly what happens with the body element. > > document.activeElement returns the body element in a window and the body is > > "focused" just not visibly so. The same behavior should apply to dialogs, > > because it doesn't make sense to have the inert body element be the focused > > activeElement. > > I'm happy to spec the same thing for <dialog> as for <body> (your arguments > and examples make a compelling case that we should do that). However, that's > not what you're describing. > > If you think I'm wrong, educate me. Why am I seeing the behaviour I describe > in comment 55 for the test case mentioned there? How do you explain how the > VO focus doesn't follow the keyboard focus on that test? See my response in Comment #61. > How do you explain that pages get focused even though no 'focus' events fire? All browser's fire an additional notification when a web page is loaded. The auto-reading behavior you're seeing is a setting in VoiceOver Utility under Web > Page Loading. This type of notification would be inappropriate for dialogs, because the DOM node is already loaded. > How do you > explain that the confirm() dialog's text gets read out even though a button > _after_ the text is focused and remains focused the entire time? See above paragraphs starting with "AppKit-based dialogs and sheets..." and "With ARIA based dialogs..."
So what you're saying is, you have code to make native dialogs and top-level Web pages work like I say they work, but you don't want to add any more code to make <dialog> work that same way? Why not? I'm confused. (In reply to James Craig from comment #62) > > Let me clarify, any element can get focused. Some need a tabindex attribute. So, all elements can _sometimes_ get focused, sure. But you're proposing focusing elements that can't get focus at the time you want to focus them. > Perhaps what you could spec is a new behavior for the value of tabindex="-2" > which could be the default for <body> and <dialog>. Well I don't think we should make it part of tabindex="", since that would be very misleading, but yes, that's exactly what I've been proposing for a while now. Defining a focus mechanism for <dialog>s that matches that of <body>. > The primary benefit is > that it would be backwards compatible with today's behavior for tabindex, so > focus notifications would work with today's APIs while they're being updated > to match the idea you're spitballing of separate types of dialog focus, and > element focus. In the transition period, it would make sense for authors to use tabindex="-1" and role=dialog and all the other things they're using today, sure. > All browser's fire an additional notification when a web page is loaded. Exactly. I'm saying show()/showModal() should similarly do something like this. This is what built-in accessibility (as opposed to bolt-on accessibility) looks like.
(In reply to Ian 'Hixie' Hickson from comment #63) > So what you're saying is, you have code to make native dialogs and top-level > Web pages work like I say they work, but you don't want to add any more code > to make <dialog> work that same way? No. You clearly don't want to hear it, but I'm saying both native dialogs and web dialogs *rely* on element focus notifications, so the <dialog> element should be focused *by default* if nothing else inside it is focused. As I stated numerous times above, the focus notification is the API that kicks everything off for both native dialogs and retrofit ARIA dialogs. It is not an optional step. Neither native or ARIA dialog will "work" until the focus notification fires first. ... > In the transition period, it would make sense for authors to use > tabindex="-1" and role=dialog and all the other things they're using today, > sure. During the transition period, it would make sense for browsers to support expected API behavior, which means an element focus notification, instead of making up new APIs that will require updates to the keyboard access behavior of three major operating systems, five or so accessibility APIs, four rendering engines, and a large number of assistive technologies. There's no good reason to reinvent the wheel for this when a simple element focus works. If you continue along this path and ignore the backwards-compatibility of established APIs, the only thing you'll be ensuring is that <dialog> will only be useful to sighted, mouse users for years. The burden should not be on authors to make the <dialog> element accessible to keyboard and AT users, because time has proven that average web authors (and most frameworks) are incapable or unconcerned with proper behavior for these elements. All of the work to make these accessible to all users can and should be done in the rendering engine. > > All browser's fire an additional notification when a web page is loaded. The > > auto-reading behavior you're seeing is a setting in VoiceOver Utility under > > Web > Page Loading. This type of notification would be inappropriate for > > dialogs, because the DOM node is already loaded. > > Exactly. > > I'm saying show()/showModal() should similarly do something like this. This > is what built-in accessibility (as opposed to bolt-on accessibility) looks > like. Again, this type of notification would be inappropriate for dialogs, because the DOM node of the dialog is already loaded. When the user's primary context changes within a web view (as such with this dialog), an element focus notification is the correct way to convey this context change in every major API and OS.
Do you agree that an element X, when it is focusable, if it is clicked, takes the focus away from whatever other element is currently focused, and moves focus to itself, such that the element X now matches :focus and subsequence key events are targetted at this element X?
I agree with the goal that from the perspective of AT, when a modal dialog box is shown, the dialog or one of its descendants should have focus. Even if the event is fired that the dialog appeared, if AT thinks focus is on the body it's not likely to work correctly. For example, magnifiers wouldn't zoom to the bounds of the dialog box, and screen readers won't switch to application mode or focus mode, as they do now when entering a dialog. It doesn't seem ideal to focus the first focusable control if none of them has the autofocus attribute set. Authors may not want that, and it doesn't help with dialogs that don't have any focusable controls (yes, that would be poor design - but still it's a valid corner case). Is there any reason the dialog element itself couldn't be focusable - the equivalent of tabIndex=-1, like an iframe? That seems reasonable to me. So my first choice would be to just change the spec so that a dialog is focusable. However, if we can't reach consensus on that, another possible solution is that the user agent could present a slightly different model of what has focus to AT. I don't see any reason why this couldn't work here as long as it's well-defined and consistent. Specifically, when a modal dialog is active, and document.body has focus, the user agent could instead notify AT that the active dialog element has focus. That would improve the situation for existing AT without requiring any changes to the behavior for anyone else.
(In reply to Ian 'Hixie' Hickson from comment #65) > Do you agree that an element X, when it is focusable, if it is clicked, > takes the focus away from whatever other element is currently focused, and > moves focus to itself, such that the element X now matches :focus and > subsequence key events are targetted at this element X? Yes.
Do you agree that when a native dialog box has a focused text edit control, and the user clicks on the background of the dialog where no control is present, the focus remains on the text field?
(In reply to Ian 'Hixie' Hickson from comment #68) > Do you agree that when a native dialog box has a focused text edit control, > and the user clicks on the background of the dialog where no control is > present, the focus remains on the text field? (out of context): that's how dialogs usually behave on Windows, web pages do different thing. I'm not sure whether dialog element must copy native dialogs here. However it should be ok as long as authors can control it (like tabindex technique)
(In reply to Ian 'Hixie' Hickson from comment #68) > Do you agree that when a native dialog box has a focused text edit control, > and the user clicks on the background of the dialog where no control is > present, the focus remains on the text field? No. Since that's not how text field focus works within <body>, I would not expect it to work that way within a web <dialog>. A mouse click outside the focused activeElement should implicitly blur the activeElement, and explicitly focus the first focusable ancestor of the click target, including the <dialog> or <body> if no element lower in the tree captures focus.
Ah, interesting. That doesn't match platform conventions. This may be where our disagreement is stemming from. On Web pages, when you click the body, what you're really focusing is the scroll box that the body is in. That you can sort of focus it even when the body isn't scrollable seems like a bug to me. Why would we not want to match native dialogs? Isn't that pretty much the goal we should be striving for?
(In reply to Ian 'Hixie' Hickson from comment #71) > Ah, interesting. That doesn't match platform conventions. This may be where > our disagreement is stemming from. > > On Web pages, when you click the body, what you're really focusing is the > scroll box that the body is in. That you can sort of focus it even when the > body isn't scrollable seems like a bug to me. Since document.activeElement return the body element in this scenario, and all key events target the body, this is effectively identical to focusing the body. Your note about the containing scrollview seems like an implementation detail that is unrelated. > Why would we not want to match native dialogs? Isn't that pretty much the > goal we should be striving for? No. The goal should be to achieve consist behavior with web technologies across all platforms, not exactly match the behavior of each platform. If that was the goal, there would be no possible resolution, as each platform's conventions are different. There are hundreds of places the Web doesn't exactly match platform conventions, and likewise those platform conventions don't match other platform's conventions. If you wanted to treat dialog's click-to-focus-or-blur behavior differntly from that of the body element's click-to-focus-or-blur behavior, I would call that an inconsistency. If you wanted to change both body and dialog so that clicks will not implicitly blur other elements, that would at least be consistent, but I think it's probably not a great idea to change the body element's behavior here on a whim, since it's been this way for multiple decades.
Relating bug 23585 as another example of unexpected keyboard behavior in HTML.
> > Why would we not want to match native dialogs? Isn't that pretty much the > > goal we should be striving for? > > No. The goal should be to achieve consist behavior with web technologies > across all platforms, not exactly match the behavior of each platform. I have to say I quite strongly disagree here. The whole point of many aspects of the Web platform's design is that by default it should match the host platform conventions. The term "platform conventions" is used in HTML two dozen times alone. > If that was the goal, there would be no possible resolution, as each > platform's conventions are different. The resolution would be — is — to define something that doesn't precisely describe any specific platform, but provides a general framework around which any platform-specific conventions can be wrapped. We haven't always been successful at this (in particular, we've failed at doing this when it comes to user interaction events on modern touch platforms), but in general we've done a surprisingly reasonable job, IMHO. > There are hundreds of places the Web doesn't exactly match platform > conventions Please do file bugs on those. There shouldn't really be any. > If you wanted to treat dialog's click-to-focus-or-blur behavior differntly > from that of the body element's click-to-focus-or-blur behavior, I would > call that an inconsistency. It's consistent with how other dialogs (e.g. window.alert) work in the exact same context today, no? > If you wanted to change both body and dialog I agree that we can't change <body> due to legacy. It's interesting to study overflow:scroll focus behaviour. In WebKit/Blink browsers, it seems like there can be one 'scrollable' container that is the "active container" in a <body>, and while that is focused, arrow keys cause the active scrollable container to scroll. But those containers aren't focused, and they don't get an outline, and you can't tab to them. In Firefox, clicking the scrollable containers causes them to respond to arrow keys in the same way, but you can additionally tab to them just like if they were regularly focusable elements. But clicking on them unfocuses them, so they're not normal focusable elements. What would you want to have happen if you had three non-modal <dialog> elements with no focusable controls inside them? Should they be tab-focusable? Should clicking on them make them the focused control? Should :focus match them at any time?
(In reply to Ian 'Hixie' Hickson from comment #74) > > > Why would we not want to match native dialogs? Isn't that pretty much the > > > goal we should be striving for? > > > > No. The goal should be to achieve consistent behavior with web technologies > > across all platforms, not exactly match the behavior of each platform. > > I have to say I quite strongly disagree here. The whole point of many > aspects of the Web platform's design is that by default it should match the > host platform conventions. The term "platform conventions" is used in HTML > two dozen times alone. I'm not saying things like modifier keys need to be identical across platforms, but focus behavior should be predictable so that an web page author does not have to special-case each system. > > If that was the goal, there would be no possible resolution, as each > > platform's conventions are different. > > The resolution would be — is — to define something that doesn't precisely > describe any specific platform, but provides a general framework around > which any platform-specific conventions can be wrapped. We haven't always > been successful at this (in particular, we've failed at doing this when it > comes to user interaction events on modern touch platforms), but in general > we've done a surprisingly reasonable job, IMHO. I think there are a lot of full keyboard access users and assistive technology users that may disagree with your opinion. > > There are hundreds of places the Web doesn't exactly match platform > > conventions > > Please do file bugs on those. There shouldn't really be any. Listed one above. I'll continue to file more as I find them. You should file the one you mentioned about the <body> element not behaving like native platforms, even if you're just filing it to close as WONTFIX. > > If you wanted to treat dialog's click-to-focus-or-blur behavior differntly > > from that of the body element's click-to-focus-or-blur behavior, I would > > call that an inconsistency. > > It's consistent with how other dialogs (e.g. window.alert) work in the exact > same context today, no? I'm saying the behavior between <body> and <dialog> is inconsistent. > > If you wanted to change both body and dialog > > I agree that we can't change <body> due to legacy. Then I would argue that <dialog> should match <body>'s behavior. > It's interesting to study overflow:scroll focus behaviour. In WebKit/Blink > browsers, it seems like there can be one 'scrollable' container that is the > "active container" in a <body>, and while that is focused, arrow keys cause > the active scrollable container to scroll. But those containers aren't > focused, and they don't get an outline, and you can't tab to them. In > Firefox, clicking the scrollable containers causes them to respond to arrow > keys in the same way, but you can additionally tab to them just like if they > were regularly focusable elements. But clicking on them unfocuses them, so > they're not normal focusable elements. > > What would you want to have happen if you had three non-modal <dialog> > elements with no focusable controls inside them? Should they be > tab-focusable? Should clicking on them make them the focused control? Should > :focus match them at any time? Yes, and any focused element inside the dialog. dialog::focus, !dialog *::focus { /* style as an "active" dialog, similar to native key windows. */ /* Note: the !dialog bit is CSS4: http://dev.w3.org/csswg/selectors4/#subject */ }
> I'm not saying things like modifier keys need to be identical across > platforms, but focus behavior should be predictable so that an web page > author does not have to special-case each system. Why would the author have to special-case each system? The whole point is that the author shouldn't have to do anything, and yet should be able to achieve the right (by the user) result. > I think there are a lot of full keyboard access users and assistive > technology users that may disagree with your opinion. Can you elaborate? > > Please do file bugs on those. There shouldn't really be any. > > Listed one above. Which one, the <body>-without-a-scrollbar case? > I'll continue to file more as I find them. Thanks. > You should file the one you mentioned about the <body> element not behaving > like native platforms, even if you're just filing it to close as WONTFIX. There's no point me filing a bug I'm going to WONTFIX, that's just bureaucracy. > > I agree that we can't change <body> due to legacy. > > Then I would argue that <dialog> should match <body>'s behavior. Why? It's not clear to me here why consistency between <body> and <dialog> is more important than between <dialog> and native dialogs. > > What would you want to have happen if you had three non-modal <dialog> > > elements with no focusable controls inside them? Should they be > > tab-focusable? Should clicking on them make them the focused control? Should > > :focus match them at any time? > > Yes Yes to which? > and any focused element inside the dialog. I was talking specifically about cases without a focusable element child. However, this is a whole new can of worms. You want there to be multiple focused elements at once? I mean, I agree that the dialog should be focused at the same time as the child, but that's because I think there should be two types of focus here. I thought you disagreed with that. > dialog::focus, !dialog *::focus { > /* style as an "active" dialog, similar to native key windows. */ > /* Note: the !dialog bit is CSS4: > http://dev.w3.org/csswg/selectors4/#subject */ > } "::focus" as in a pseudo-element? Or is that at typo? I don't understand what this means at all. Also why would you need the parent selector syntax if the dialog was focused if the dialog matched :focus at the same time?
(In reply to Ian 'Hixie' Hickson from comment #76) > > I'm not saying things like modifier keys need to be identical across > > platforms, but focus behavior should be predictable so that an web page > > author does not have to special-case each system. > > Why would the author have to special-case each system? The whole point is > that the author shouldn't have to do anything, and yet should be able to > achieve the right (by the user) result. What's right by the user for dialogs is that they should be usable with a keyboard, or an AT. The current model for non-linear navigation in HTML is very mouse-centric. > > I think there are a lot of full keyboard access users and assistive > > technology users that may disagree with your opinion. > > Can you elaborate? One problem that comes to mind is that there is currently no defined way to get keyboard focus into and out of a shadow DOM component. There is also no contextual scoping for tabindex, so any web app attempting to maintain a non-DOM-ordered tab order has to manage focus for every focusable element in the DOM, when the scoping could behave more like positioning contexts in CSS. A third example is that there is no way to quickly navigate (non-linearly) to landmarks like the header or footer, or toolbars in web applications, even though platform shortcuts for these navigation patterns exist. There are dozens more examples like this. > > > Please do file bugs on those. There shouldn't really be any. > > > > Listed one above. > > Which one, the <body>-without-a-scrollbar case? bug 23585 > > I'll continue to file more as I find them. > > Thanks. > > > You should file the one you mentioned about the <body> element not behaving > > like native platforms, even if you're just filing it to close as WONTFIX. > > There's no point me filing a bug I'm going to WONTFIX, that's just > bureaucracy. The point is that it shows a conscious decision to not fix that issue, and provides some reasoning for any duplicates that get filed. > > > I agree that we can't change <body> due to legacy. > > > > Then I would argue that <dialog> should match <body>'s behavior. > > Why? It's not clear to me here why consistency between <body> and <dialog> > is more important than between <dialog> and native dialogs. Because native dialogs behave differently on each platform, so matching the platform behavior exactly would result in difficult to manage web behavior. The body element behaves consistently across browsers and platforms (at least wrt focus), and I believe that should be the model here. > > > What would you want to have happen if you had three non-modal <dialog> > > > elements with no focusable controls inside them? Should they be > > > tab-focusable? Yes > > > Should clicking on them make them the focused control? Clicking on the dialog should make it the focused element. > > > Should :focus match them at any time? Define "at any time"? The focus state should match when the dialog itself is focused ("dialog:focus"), and the other selector should match when any descendant of the dialog is focused ("!dialog *:focus"). > > and any focused element inside the dialog. > > I was talking specifically about cases without a focusable element child. > > However, this is a whole new can of worms. You want there to be multiple > focused elements at once? > > I mean, I agree that the dialog should be focused at the same time as the > child, but that's because I think there should be two types of focus here. I > thought you disagreed with that. The key window should be styled as "active" when it or one of its descendants has focus. See the selector explanation below. > > dialog::focus, !dialog *::focus { > > /* style as an "active" dialog, similar to native key windows. */ > > /* Note: the !dialog bit is CSS4: > > http://dev.w3.org/csswg/selectors4/#subject */ > > } > > "::focus" as in a pseudo-element? Or is that at typo? I don't understand > what this means at all. Also why would you need the parent selector syntax > if the dialog was focused if the dialog matched :focus at the same time? Yes, sorry. Single colon pseudo-class, not pseudo-element. The second selector ("!dialog *:focus") means "selects a dialog when any element inside it has focus" as opposed to ("dialog *:focus") when means "select any element with focus that is inside a dialog". See CSS4 subject selector: http://dev.w3.org/csswg/selectors4/#subject
I guess I don't understand why dialogs in HTML should behave differently than native ones. If I load Safari and open the preferences dialog and the about dialog, I can't tab between them. To switch between them, I have to use Command+`. When I have a pref pane in Safari's preferences dialog with multiple focusable controls, and I focus one, and then switch to another window and back again, that control is still focused. There's clearly two concepts, "focused window" and "focused control", that are distinct in this scenario. The Web attempts to provide a way to create native-like experiences in a platform-independent way. That means that on each host platform, Web widgets work as the native widgets do. Checkboxes in Mac Firefox and checkboxes in Windows Firefox look different. > One problem that comes to mind is that there is currently no defined way to > get keyboard focus into and out of a shadow DOM component. Please file a bug on this. > There is also no > contextual scoping for tabindex, so any web app attempting to maintain a > non-DOM-ordered tab order has to manage focus for every focusable element in > the DOM, when the scoping could behave more like positioning contexts in > CSS. Please file a bug on this. > A third example is that there is no way to quickly navigate > (non-linearly) to landmarks like the header or footer, or toolbars in web > applications, even though platform shortcuts for these navigation patterns > exist. Isn't that just a bug with the ATs? I don't see what would prevent this from being possible. > There are dozens more examples like this. Please file bugs for them. > > > > Please do file bugs on those. There shouldn't really be any. > > > > > > Listed one above. > > > > Which one, the <body>-without-a-scrollbar case? > > bug 23585 That bug appears to be a bug on the W3C spec. The WHATWG spec doesn't have that problem, for what it's worth; there's an explicit requirement that when an element stop being rendered, it lose focus: "An element is focusable if [...] The element is [...] being rendered [...]. When an element that is focused stops being a focusable element [...] the user agent should synchronously run the unfocusing steps for the affected element only." In any case, if you want me to fix bugs in HTML, please make sure you file them on the WHATWG component, or I won't see them. > > There's no point me filing a bug I'm going to WONTFIX, that's just > > bureaucracy. > > The point is that it shows a conscious decision to not fix that issue, and > provides some reasoning for any duplicates that get filed. Well, if there's not been a conscious decision, or if you're not sure if there has been one, then sure. File away! :-) No need to worry about the duplicates until we get one. > > Why? It's not clear to me here why consistency between <body> and <dialog> > > is more important than between <dialog> and native dialogs. > > Because native dialogs behave differently on each platform, so matching the > platform behavior exactly would result in difficult to manage web behavior. I don't understand why authors would need to manage anything here. The entire point, as I noted earlier, is to manage this for them. What is it you see as needing to be managed? This is similar to how on Windows, check boxes are always focusable, but on Mac, check boxes aren't always focusable. There's nothing for authors to manage: it's just taken care of for them. > The body element behaves consistently across browsers and platforms (at > least wrt focus), and I believe that should be the model here. It doesn't really behave that consistently. See the penultimate paragraph of comment 74. > > > > Should :focus match them at any time? > > Define "at any time"? I mean, should there be times where :focus matches one of them. > Yes, sorry. Single colon pseudo-class, not pseudo-element. The second > selector ("!dialog *:focus") means "selects a dialog when any element inside > it has focus" as opposed to ("dialog *:focus") when means "select any > element with focus that is inside a dialog". See CSS4 subject selector: > http://dev.w3.org/csswg/selectors4/#subject I'm familiar with Selectors, I'm just trying to work out if you meant that there should ever be two elements matching :focus at once, or if you just meant that we should style the <dialog> such that it looks different when either it or something inside it matches :focus, without actually making it match :focus itself in the case of it containing something that matches :focus. I have a better understanding now of what you're proposing, and I think it can probably be made to work, but I still don't understand why we would want to do things that way. It seems contrary to HTML's design philosophy. I think a better solution would be to formalise the separate concept of "focused window", and define how focus works in the new world where HTML documents can have such things.
(In reply to Ian 'Hixie' Hickson from comment #78) > I guess I don't understand why dialogs in HTML should behave differently > than native ones. > > If I load Safari and open the preferences dialog and the about dialog, I > can't tab between them. To switch between them, I have to use Command+`. > When I have a pref pane in Safari's preferences dialog with multiple > focusable controls, and I focus one, and then switch to another window and > back again, that control is still focused. There's clearly two concepts, > "focused window" and "focused control", that are distinct in this scenario. While I agree that HTML needs some kind of tabindex "scoping", that's a separate issue. And again, what you're referring to is not "window focus" but is actually called the "key window" (Look up Cocoa's concept of a "first responder chain") > The Web attempts to provide a way to create native-like experiences in a > platform-independent way. That means that on each host platform, Web widgets > work as the native widgets do. Checkboxes in Mac Firefox and checkboxes in > Windows Firefox look different. But from the web author's perspective, they don't *behave* differently. The focus behavior needs to be consistent here so that web applications can predictably code for them. > > One problem that comes to mind is that there is currently no defined way to > > get keyboard focus into and out of a shadow DOM component. > > Please file a bug on this. bug 23870 > > There is also no > > contextual scoping for tabindex, so any web app attempting to maintain a > > non-DOM-ordered tab order has to manage focus for every focusable element in > > the DOM, when the scoping could behave more like positioning contexts in > > CSS. > > Please file a bug on this. bug 23871 > > A third example is that there is no way to quickly navigate > > (non-linearly) to landmarks like the header or footer, or toolbars in web > > applications, even though platform shortcuts for these navigation patterns > > exist. > > Isn't that just a bug with the ATs? I don't see what would prevent this from > being possible. Reminder that I'm talking about full keyboard access, not ATs. A user should not have to use a mouse or an assistive technology in order to access the Web. A keyboard should be sufficient. > > There are dozens more examples like this. > > Please file bugs for them. > > > > > > > Please do file bugs on those. There shouldn't really be any. > > > > > > > > Listed one above. > > > > > > Which one, the <body>-without-a-scrollbar case? > > > > bug 23585 > > That bug appears to be a bug on the W3C spec. The WHATWG spec doesn't have > that problem, for what it's worth; there's an explicit requirement that when > an element stop being rendered, it lose focus: Please provide a link to the edit in the related bug, so that that it can be fixed in the W3C spec, too. > "An element is focusable if [...] The element is [...] being rendered [...]. > When an element that is focused stops being a focusable element [...] the > user agent should synchronously run the unfocusing steps for the affected > element only." > > In any case, if you want me to fix bugs in HTML, please make sure you file > them on the WHATWG component, or I won't see them. You're listed in the CC. > This is similar to how on Windows, check boxes are always focusable, but on > Mac, check boxes aren't always focusable. There's nothing for authors to > manage: it's just taken care of for them. That > > The body element behaves consistently across browsers and platforms (at > > least wrt focus), and I believe that should be the model here. > > It doesn't really behave that consistently. See the penultimate paragraph of > comment 74. > > > > > > > Should :focus match them at any time? > > > > Define "at any time"? > > I mean, should there be times where :focus matches one of them. I've lost the context of this question, but yes. There should be a time when :focus matches either an element inside the dialog or the dialog itself. > > Yes, sorry. Single colon pseudo-class, not pseudo-element. The second > > selector ("!dialog *:focus") means "selects a dialog when any element inside > > it has focus" as opposed to ("dialog *:focus") when means "select any > > element with focus that is inside a dialog". See CSS4 subject selector: > > http://dev.w3.org/csswg/selectors4/#subject > > I'm familiar with Selectors, I'm just trying to work out if you meant that > there should ever be two elements matching :focus at once No. > or if you just > meant that we should style the <dialog> such that it looks different when > either it or something inside it matches :focus, without actually making it > match :focus itself in the case of it containing something that matches > :focus. This is what I intended. Sorry it wasn't clear. > I have a better understanding now of what you're proposing, and I think it > can probably be made to work, but I still don't understand why we would want > to do things that way. It seems contrary to HTML's design philosophy. I don't see how this is against HTML's design philosophy. > I think a better solution would be to formalise the separate concept of > "focused window", and define how focus works in the new world where HTML > documents can have such things. I'm fine with defining new concept of window focus if you want that as an *addition* to element focus, but in the case where there is a dialog with nothing focused inside, document.activeElement should be the dialog and trigger a standard onfocus event.
(In reply to James Craig from comment #79) > (In reply to Ian 'Hixie' Hickson from comment #78) > > > This is similar to how on Windows, check boxes are always focusable, but on > > Mac, check boxes aren't always focusable. There's nothing for authors to > > manage: it's just taken care of for them. > > That Got ahead of myself. I meant to say that inconsistencies like this causes issues with event handling in some enterprise-scale web apps, and is part of the reason we're considering exposing some user preferences to web apps as part of the IndieUI User Context draft, as either a JS interface, or as media queries. I agree that web "dialogs" should be managed for the simple cases, but focus behavior and related notifications should be specified so that web apps needing to tap into the dialog behavior can behave consistently across every UA implementation.
> > If I load Safari and open the preferences dialog and the about dialog, I > > can't tab between them. To switch between them, I have to use Command+`. > > When I have a pref pane in Safari's preferences dialog with multiple > > focusable controls, and I focus one, and then switch to another window and > > back again, that control is still focused. There's clearly two concepts, > > "focused window" and "focused control", that are distinct in this scenario. > > While I agree that HTML needs some kind of tabindex "scoping", that's a > separate issue. What I describe above isn't about tabindex="", it's about different windows, each of which can be "focused", with there being one "currently focused" window in the system, and different controls within a window, each of which can be "focused", with there being one "currently focused" control within each window. > And again, what you're referring to is not "window focus" > but is actually called the "key window" (Look up Cocoa's concept of a "first > responder chain") The terms differ from platform to platform; it doesn't really matter what term we use. The terms "focused window" and "focused control" seems simplest and clearest. > > The Web attempts to provide a way to create native-like experiences in a > > platform-independent way. That means that on each host platform, Web widgets > > work as the native widgets do. Checkboxes in Mac Firefox and checkboxes in > > Windows Firefox look different. > > But from the web author's perspective, they don't *behave* differently. Sure they do. Text selection, for instance, works differently on Windows and Mac (and even more differently on esoteric platforms like Emacs or those based on WordStar semantics). Whether a control is focusable or not differs on Mac and Windows (and can differ even on one platform, due to user preferences). > The > focus behavior needs to be consistent here so that web applications can > predictably code for them. I disagree with the premise of your statement, but I don't really see how this is relevant to this bug. I'm not proposing making things different on different platforms. Mac, Windows, X, Android, and every other GUI platform I know of (except maybe RISC OS? I forget how they do window focus) has this same concept of focused window. Designing HTML around this same concept would give consistent behaviour to authors. > bug 23870 > bug 23871 These aren't filed on the WHATWG spec; if you want me to address them please move them to the WHATWG component. > You're listed in the CC. I receive hundreds of bug mails a day. I don't have the bandwidth to read them with anything like reasonable latency. You should assume I only look at the bugs assigned to me. Sorry. > > > A third example is that there is no way to quickly navigate > > > (non-linearly) to landmarks like the header or footer, or toolbars in web > > > applications, even though platform shortcuts for these navigation patterns > > > exist. > > > > Isn't that just a bug with the ATs? I don't see what would prevent this from > > being possible. > > Reminder that I'm talking about full keyboard access, not ATs. A user should > not have to use a mouse or an assistive technology in order to access the > Web. A keyboard should be sufficient. Either way, isn't it just a bug? There's nothing that prevents this today. > > This is similar to how on Windows, check boxes are always focusable, but on > > Mac, check boxes aren't always focusable. There's nothing for authors to > > manage: it's just taken care of for them. > > Inconsistencies like this causes > issues with event handling in some enterprise-scale web apps, and is part of > the reason we're considering exposing some user preferences to web apps as > part of the IndieUI User Context draft, as either a JS interface, or as > media queries. That, IMHO, would be a huge mistake. It shouldn't cause any trouble for authors if they're writing HTML properly. The whole point of HTML is to abstract this kind of thing out for them. I would be interested in hearing more about how authors are getting themselves into trouble here. Could you e-mail me about it? > I agree that web "dialogs" should be managed for the simple cases, but focus > behavior and related notifications should be specified so that web apps > needing to tap into the dialog behavior can behave consistently across every > UA implementation. I'm all for specifying it, so long as it's consistent with host platform semantics. > > I have a better understanding now of what you're proposing, and I think it > > can probably be made to work, but I still don't understand why we would want > > to do things that way. It seems contrary to HTML's design philosophy. > > I don't see how this is against HTML's design philosophy. HTML's design philosophy is to abstract out platform-specific details so that an application written in HTML can work on any platform in a native-like manner. The model you describe isn't like any native platform's model. > > I think a better solution would be to formalise the separate concept of > > "focused window", and define how focus works in the new world where HTML > > documents can have such things. > > I'm fine with defining new concept of window focus if you want that as an > *addition* to element focus, but in the case where there is a dialog with > nothing focused inside, document.activeElement should be the dialog and > trigger a standard onfocus event. Why would we make the case of there being focused controls different from the case of there being no focused controls? I don't understand why activeElement matters here. Thinking about what the right model should be: We could have a model where document.activeElement points to a <dialog>, and the <dialog> itself has an activeElement that points to the active control, and make <body> and <dialog> elements into similar concepts, focus-wise. We could have a model where document.activeElement points to the currently focused control, and, say, document.activeDialog points to the currently active dialog. How we send events to indicate that a <dialog> has focus is unclear. The problem with using 'focus' and 'blur' events is that it would mean there would be no way to distinguish a <dialog> with tabindex="" set receiving control focus from it receiving window focus. We could not allow <dialog> to get tabindex="". We could allow it, and use different events (e.g. just dialogfocused, or dialogfocusin and dialogfocusout). API-wise, it probably looks better if we allow dialog.focus() to focus the dialog as the focused dialog (as opposed to the focused control). Maybe it just happens to do both if you have a <dialog> with tabindex="", rather than tracking who had focus before. Whether :focus should match a focused dialog that doesn't have control focus is an interesting question. We presumably do need a pseudo that matches a dialog with window focus. Why not make it :focus, since the only time that would be confusing is when you had a <dialog> with tabindex="" that was focused both ways, but then that's a weird case anyway. How about controls that are the focused control of a <dialog> when the <dialog> isn't focused? Do they match :focus? Probably not, but some platforms do style would-be-focused controls in non-focused windows in a recognisable way. What we do with z-index on non-modal <dialog>s is another interesting question. Probably nothing, by default?
(In reply to Ian 'Hixie' Hickson from comment #81) > > bug 23870 > > bug 23871 > > These aren't filed on the WHATWG spec; if you want me to address them please > move them to the WHATWG component. I filed them against the W3C spec. The editors can clone them for WHATWG if they feel it's necessary, or you can clone them if you'd like to track the issues there as well. > It shouldn't cause any trouble for authors if they're writing HTML properly. > The whole point of HTML is to abstract this kind of thing out for them. > > I would be interested in hearing more about how authors are getting > themselves into trouble here. Could you e-mail me about it? It's too long a discussion for email or Bugzilla. Perhaps we'll be in the same watering hole one day and I'll give you the details. > HTML's design philosophy is to abstract out platform-specific details so > that an application written in HTML can work on any platform in a > native-like manner. The model you describe isn't like any native platform's > model. And yet UI Element focus notifications are what make these dialogs "work" on every platform. > > > I think a better solution would be to formalise the separate concept of > > > "focused window", and define how focus works in the new world where HTML > > > documents can have such things. > > > > I'm fine with defining new concept of window focus if you want that as an > > *addition* to element focus, but in the case where there is a dialog with > > nothing focused inside, document.activeElement should be the dialog and > > trigger a standard onfocus event. > > Why would we make the case of there being focused controls different from > the case of there being no focused controls? I don't understand why > activeElement matters here. I understand you'd like a new distinction between "focused control" and "focused window" but both are elements, and one of them MUST get a system focus notification in order for the dialog concept to "work", hence the Bugzilla issue. What is required here is "element focus" regardless of whether that element is a form control or a dialog element. If you add this new distinction, you should specify appropriate behavior where it does not apply. Something like this: 1. On platforms that maintain a distinction between 'window focus' and 'control focus', the dialog becomes the focused window, and the first element matching [autofocus] becomes the focused control. 2. For dialogs with no focusable elements on platforms that do maintain a concept of 'window focus', the dialog becomes the focused window, and there is no focused control. 3. For dialogs with no focusable elements on platforms that do *not* maintain a concept of 'window focus', the user agent SHOULD fire a system focus notification on the dialog element itself. > Whether :focus should match a focused dialog that doesn't have control focus > is an interesting question. We presumably do need a pseudo that matches a > dialog with window focus. Why not make it :focus, since the only time that > would be confusing is when you had a <dialog> with tabindex="" that was > focused both ways, but then that's a weird case anyway. > > How about controls that are the focused control of a <dialog> when the > <dialog> isn't focused? Do they match :focus? Probably not, but some > platforms do style would-be-focused controls in non-focused windows in a > recognisable way. dialog:not(:focus) *:focus { /* focused element in non-focused dialog */ }
> > HTML's design philosophy is to abstract out platform-specific details so > > that an application written in HTML can work on any platform in a > > native-like manner. The model you describe isn't like any native platform's > > model. > > And yet UI Element focus notifications are what make these dialogs "work" on > every platform. I don't understand what you mean here. The Web platform API doesn't have to be a precise mapping of the underlying platform API. In fact it's better if it's not, since otherwise the abstraction can easily break down (see e.g. the mess we're in with touch vs keyboard vs mouse input on mobile, or the issues with zoom on mobile, which are caused by not abstracting the underlying platform enough). But that doesn't mean that we can't send the native platform whatever notifications it needs. That is, even if we had a "dialogfocus" event and a "focus" event, if the underlying platform wants a "UI Element focus notification" when you change focused window, we can still send that to the platform, regardless of what we send the Web page. > > Why would we make the case of there being focused controls different from > > the case of there being no focused controls? I don't understand why > > activeElement matters here. > > I understand you'd like a new distinction between "focused control" and > "focused window" but both are elements, and one of them MUST get a system > focus notification in order for the dialog concept to "work", hence the > Bugzilla issue. The HTML 'focus' event has nothing to do with what the underlying platform notifications are. I don't understand why you think they need be related. Is there some key thing I'm missing? Earlier you were arguing that we should present a "unified front" to Web developers. Surely that should lead to more abstraction, not less, and thus we should try not to expose these platform-specific idiosyncrasies, by not exposing system notifications at all, but instead exposing to Web authors only the events that make sense given the abstract model (e.g. fire focus/blur to controls, and windowfocus/windowblur to dialogs; or, not allow dialogs to be focusable controls, and fire the same events but have dialogs have a separate activeElement API from the body one, or have activeElement and activeDialog as separate APIs, or other things I proposed above). > What is required here is "element focus" regardless of > whether that element is a form control or a dialog element. I either do not understand what you mean, or I do not understand why you think this is the case. Can you elaborate on this? > If you add this new distinction It's not a new distinction. It's a somewhat new feature in HTML if you ignore how <iframe>s and auxiliary browsing contexts windows work, but it's a distinction that every host platform already has. > 1. On platforms that maintain a distinction between 'window focus' and > 'control focus', the dialog becomes the focused window, and the first > element matching [autofocus] becomes the focused control. Sure. > 2. For dialogs with no focusable elements on platforms that do maintain a > concept of 'window focus', the dialog becomes the focused window, and there > is no focused control. Right. > 3. For dialogs with no focusable elements on platforms that do *not* > maintain a concept of 'window focus', the user agent SHOULD fire a system > focus notification on the dialog element itself. In principle that seems reasonable, though it wouldn't need to be exposed at the level of the HTML API so it seems like an implementation detail. But what platforms do not maintain a concept of 'window focus'? I've been looking everywhere I can and I can't find one. RISC OS, the only WIMP-based GUI OS I could think of that I wasn't sure had it, does have it. X certainly has it, even when you have weird window managers like ion3 with focus-follows-mouse. Mac and Windows certainly have it (and they have keyboard shortcuts for navigating windows separate from controls). Even non-WIMP UIs that are barely GUIs, like Emacs, have it. The only platforms I can think of that don't have a concept of focused window are the platforms that don't have a concept of window in the first place, like, say, DOS. Even mobile platforms without a keyboard, like Android, have a concept of focused window. Even iOS, which as far as I can tell doesn't support external keyboard input at all, have a concept of focused window (see e.g. what happens when you get an alert). So what platform would this be relevant to? > > Whether :focus should match a focused dialog that doesn't have control focus > > is an interesting question. We presumably do need a pseudo that matches a > > dialog with window focus. Why not make it :focus, since the only time that > > would be confusing is when you had a <dialog> with tabindex="" that was > > focused both ways, but then that's a weird case anyway. > > > > How about controls that are the focused control of a <dialog> when the > > <dialog> isn't focused? Do they match :focus? Probably not, but some > > platforms do style would-be-focused controls in non-focused windows in a > > recognisable way. > > dialog:not(:focus) *:focus { /* focused element in non-focused dialog */ } Yeah, that's how we'd do it if we decide that elements representing the focused window can match :focus at the same time as other elements representing the focused control, even when those controls are in windows that aren't focused. But then you'd have this weird situation where lots of elements can match :focus at once, which is a bit weird. Might be best to have a new pseudo-class. It depends a little on how intuitive it is for authors (if it's not intuitive, and they have straight :focus rules, we might end up with very confusing UIs where multiple controls have focus outlines and the user can't tell where keyboard input will go, which would be pretty bad). It's possible that we're just talking at cross-purposes because there's no concrete proposal on the table. I guess I'll try to make a concrete proposal and we can then talk about specific concerns you may have with that proposal rather than trying to argue them before we know what we're considering. If you have any preferences amongst the options I listed at the end of comment 81, please let me know.
(In reply to Ian 'Hixie' Hickson from comment #83) > > If you add this new distinction > > It's not a new distinction. It's a somewhat new feature in HTML if you > ignore how <iframe>s and auxiliary browsing contexts windows work, but it's > a distinction that every host platform already has. The concept of styling the frontmost window exists, but it is separate from the idea of "focus." > > 1. On platforms that maintain a distinction between 'window focus' and > > 'control focus', the dialog becomes the focused window, and the first > > element matching [autofocus] becomes the focused control. > > Sure. > > > > 2. For dialogs with no focusable elements on platforms that do maintain a > > concept of 'window focus', the dialog becomes the focused window, and there > > is no focused control. > > Right. > > > > 3. For dialogs with no focusable elements on platforms that do *not* > > maintain a concept of 'window focus', the user agent SHOULD fire a system > > focus notification on the dialog element itself. > > In principle that seems reasonable, though it wouldn't need to be exposed at > the level of the HTML API so it seems like an implementation detail. If it's not in the spec, you're going to have different opinions of how this should be implemented, it will end up being inconsistent, and once again authors will have to work around the shortcomings of HTML to make their interfaces work for all users. Most won't, so a keyboard users experience on the Web will suffer. > what platforms do not maintain a concept of 'window focus'? I've been > looking everywhere I can and I can't find one. Several times in this thread I've mentioned that, to my knowledge, none of them do. I think we have a vocabulary mismatch. Perhaps I should have said: "on platforms that do *not* maintain a concept of a 'window focus event/notification' separate from that of a 'focus event/notification' the user agent SHOULD fire a system focus notification on the dialog element itself." > > > Whether :focus should match a focused dialog that doesn't have control focus > > > is an interesting question. We presumably do need a pseudo that matches a > > > dialog with window focus. Why not make it :focus, since the only time that > > > would be confusing is when you had a <dialog> with tabindex="" that was > > > focused both ways, but then that's a weird case anyway. > > > > > > How about controls that are the focused control of a <dialog> when the > > > <dialog> isn't focused? Do they match :focus? Probably not, but some > > > platforms do style would-be-focused controls in non-focused windows in a > > > recognisable way. > > > > dialog:not(:focus) *:focus { /* focused element in non-focused dialog */ } > > Yeah, that's how we'd do it if we decide that elements representing the > focused window can match :focus at the same time as other elements > representing the focused control, even when those controls are in windows > that aren't focused. But then you'd have this weird situation where lots of > elements can match :focus at once, which is a bit weird. Might be best to > have a new pseudo-class. It depends a little on how intuitive it is for > authors (if it's not intuitive, and they have straight :focus rules, we > might end up with very confusing UIs where multiple controls have focus > outlines and the user can't tell where keyboard input will go, which would > be pretty bad). > > It's possible that we're just talking at cross-purposes because there's no > concrete proposal on the table. I guess I'll try to make a concrete proposal > and we can then talk about specific concerns you may have with that proposal > rather than trying to argue them before we know what we're considering. If > you have any preferences amongst the options I listed at the end of comment > 81, please let me know. Here's my updated change proposal, accounting for our previous vocabulary mismatch: 1. On platforms that maintain a distinction between a 'window focus notification' and a 'control focus notification', the dialog becomes the focused window, and the first element matching [autofocus] becomes the focused control, otherwise, the first focusable element becomes the focused control. 2. For dialogs with no focusable elements on platforms that do maintain a concept of a 'window focus notification', the dialog becomes the focused window, and there is no focused control. 3. For dialogs with no focusable elements on platforms that do *not* maintain a concept of a 'window focus notification' separate from that of a standard 'control focus notification', the dialog itself becomes the focused control.
(In reply to James Craig from comment #84) > (In reply to Ian 'Hixie' Hickson from comment #83) > > > If you add this new distinction > > > > It's not a new distinction. It's a somewhat new feature in HTML if you > > ignore how <iframe>s and auxiliary browsing contexts windows work, but it's > > a distinction that every host platform already has. > > The concept of styling the frontmost window exists, but it is separate from > the idea of "focus." It doesn't have to be the front-most window. There's plenty of systems on which the window to which key events are routed can be a background window (e.g. on X Windows when you have "focus follows mouse" but don't have "autoraise"). And it absolutely has to do with focus, if by "focus" you mean the concept of where key events are routed. > > > 3. For dialogs with no focusable elements on platforms that do *not* > > > maintain a concept of 'window focus', the user agent SHOULD fire a system > > > focus notification on the dialog element itself. > > > > In principle that seems reasonable, though it wouldn't need to be exposed at > > the level of the HTML API so it seems like an implementation detail. > > If it's not in the spec, you're going to have different opinions of how this > should be implemented, it will end up being inconsistent, and once again > authors will have to work around the shortcomings of HTML to make their > interfaces work for all users. Most won't, so a keyboard users experience on > the Web will suffer. I completely disagree with this. It's like saying that authors have to deal with some browsers having tabs at the top and some having tabs at the bottom and others not having tabs at all. The entire point of the Web platform is to abstract out this kind of concern, so that Web authors don't have to worry about it at all. If you have a specific concrete case where authors would have to work around differences, please let me know with an example. > > what platforms do not maintain a concept of 'window focus'? I've been > > looking everywhere I can and I can't find one. > > Several times in this thread I've mentioned that, to my knowledge, none of > them do. I think we have a vocabulary mismatch. > > Perhaps I should have said: > > "on platforms that do *not* maintain a concept of a 'window focus > event/notification' separate from that of a 'focus event/notification' the > user agent SHOULD fire a system focus notification on the dialog element > itself." How the notifications work on the system level is an implementation detail. You could, on all platforms I know of, trivially distinguish a window getting focus from a control getting focus even if the event ID was the same, since one would be sent to a window, and the other would be sent to a control, and those are very different types of objects. > Here's my updated change proposal, accounting for our previous vocabulary > mismatch: > > 1. On platforms that maintain a distinction between a 'window focus > notification' and a 'control focus notification', the dialog becomes the > focused window, and the first element matching [autofocus] becomes the > focused control, otherwise, the first focusable element becomes the focused > control. Ok. > 2. For dialogs with no focusable elements on platforms that do maintain a > concept of a 'window focus notification', the dialog becomes the focused > window, and there is no focused control. > > 3. For dialogs with no focusable elements on platforms that do *not* > maintain a concept of a 'window focus notification' separate from that of a > standard 'control focus notification', the dialog itself becomes the focused > control. I disagree that any platform with windows lacks a concept of focused window distinct from the concept of focused control, so this seems moot to me. For example, on Mac you use different keys to switch between controls than to switch between windows; when you tab from the last control in a window, you jump to the first control in the same window, not to the next window; on Windows the WM_ACTIVATE and WM_SETFOCUS messages are entirely different; on X Windows window focus is handled by the window manager while control focus is handled by the application... Sure, they may have things in common (especially on X Windows and Mac they generally use common infrastructure), but that doesn't mean they're the same. I actually was working on a proposal for this over the last couple of days as well. It ended up being more about the focus system than about the focus steps in showModal(), so I posted it in bug 23475, so that we can track these as separate issues. As far as the core issue of this bug goes, I'm fine with moving keyboard focus to the first control by default rather than leaving the focus nowhere.
Checked in as WHATWG revision r8338. Check-in comment: Make <dialog> autofocus the first focusable control if there isn't one with autofocus=''. http://html5.org/tools/web-apps-tracker?from=8337&to=8338
(In reply to contributor from comment #86) > Checked in as WHATWG revision r8338. > Check-in comment: Make <dialog> autofocus the first focusable control if > there isn't one with autofocus=''. > http://html5.org/tools/web-apps-tracker?from=8337&to=8338 This phrasing is weird. > Let control be the first element in tree order whose nearest ancestor dialog > element is subject and that has an autofocus attribute specified, if any. Makes it sound like the ancestor dialog is the one with autofocus: <dialog autofocus=""> What about: Let control be the first element, if any, in tree order that has an autofocus attribute specified and whose nearest ancestor dialog element is subject. Ditto reorder for the second statement: If there isn't one, then let control be the first element, if any, in tree order that is focusable and whose nearest ancestor dialog element is subject. On the last bit: > If there isn't one of those either but subject itself is focusable, then let > control be subject. (This is unusual.) This would allow at least allow <dialog tabindex="0"> to be focused, but not necessarily <dialog> by default, correct? I think you're also implying here that implementations can fire their equivalent of "window focus" on this, which is fine. The only bit I think is missing is the parts you discussed about how to track a dialog:focus pseudo class. I am not entirely convinced this edit is sufficient, but I'm willing to let that last distinction drop for the sake of getting the rest of this edit in. Let's try this in implementations and see if we end up with additional problems. If so, we can always file another bug. This one is pushing 100 comments and getting very long in the tooth. Thanks Ian.
> This phrasing is weird. I've switched the order of the phrases around to try to make it clearer. Thanks. > This would allow at least allow <dialog tabindex="0"> to be focused, but not > necessarily <dialog> by default, correct? Depends what you mean by "focused". See the proposal in bug 23475 for details of what I'm intending to do with regard to that.
Checked in as WHATWG revision r8340. Check-in comment: Rearrange text from r8338 to be less ambiguous. http://html5.org/tools/web-apps-tracker?from=8339&to=8340