Split from the review of #14739.
On a document with no navbar, the color-scheme toggle is injected by the after-body script and its container is appended to body, so it is the last element in the DOM. Reading order and focus order both follow DOM order here, since nothing sets tabindex. The toggle is drawn at the top right of the page, so it is the first control a sighted user sees and the last one a keyboard or screen reader user reaches.
Measured on a document with a title block banner (author link, affiliation link, DOI link):
visual order TOGGLE (top=17) -> title (top=42) -> A Person (226) -> Example Org (226) -> DOI (284)
focus order now A Person -> Example Org -> DOI -> body link -> TOGGLE
A website is not affected. There the toggle sits in the navbar and is reached in navbar order, matching where it is drawn.
This is not a WCAG failure. Focus order still preserves meaning and operability, and axe reports nothing. It is a usability wrinkle, and it predates #14739: the toggle was appended to body before that change as well.
Inserting the container at the start of body instead of appending it corrects the order and leaves the drawn position untouched:
prepended -> position: {"top":17,"fromRight":17} (unchanged)
prepended -> focus : TOGGLE -> A Person -> Example Org -> DOI -> body link
The container must stay a direct child of body: the toggle is positioned against the page, so any ancestor that establishes a containing block captures it (see #14739).
Two things to check before making the change:
- It alters focus order for every existing plain document with a light/dark theme pair.
- The container would become
body's first child, so any body > *:first-child rule in a theme could pick it up.
On a plain document without a banner the toggle is drawn level with the title but to its right, so prepending puts it one position early rather than exactly right. That is still much closer than last on the page.
Part of #8706.
Split from the review of #14739.
On a document with no navbar, the color-scheme toggle is injected by the after-body script and its container is appended to
body, so it is the last element in the DOM. Reading order and focus order both follow DOM order here, since nothing setstabindex. The toggle is drawn at the top right of the page, so it is the first control a sighted user sees and the last one a keyboard or screen reader user reaches.Measured on a document with a title block banner (author link, affiliation link, DOI link):
A website is not affected. There the toggle sits in the navbar and is reached in navbar order, matching where it is drawn.
This is not a WCAG failure. Focus order still preserves meaning and operability, and axe reports nothing. It is a usability wrinkle, and it predates #14739: the toggle was appended to
bodybefore that change as well.Inserting the container at the start of
bodyinstead of appending it corrects the order and leaves the drawn position untouched:The container must stay a direct child of
body: the toggle is positioned against the page, so any ancestor that establishes a containing block captures it (see #14739).Two things to check before making the change:
body's first child, so anybody > *:first-childrule in a theme could pick it up.On a plain document without a banner the toggle is drawn level with the title but to its right, so prepending puts it one position early rather than exactly right. That is still much closer than last on the page.
Part of #8706.