Skip to content

Commit

Permalink
Changes from the meeting
Browse files Browse the repository at this point in the history 
https://www.w3.org/2020/06/30-ag-minutes.html#item02
  • Loading branch information
@alastc
alastc committed Jun 30, 2020
1 parent 07eca55 commit bedbdda
Show file tree
Hide file tree
Showing 2 changed files with 8 additions and 0 deletions.
1 change: 1 addition & 0 deletions guidelines/sc/22/focus-visible-enhanced.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,7 @@ <h4>Focus Visible (Enhanced)</h4>
<li><strong>Minimum area:</strong> The <a>focus indication area</a> is greater than or equal to a 1 <a>CSS pixel</a> border of the focused control, or has a thickness of at least 8 CSS pixels along the shortest side of the element.</li>
<li><strong>Change of contrast:</strong> Color changes used to indicate focus have a contrast ratio of at least 3:1 with the colors changed from the unfocused control.</li>
<li><strong>Adjacent contrast:</strong> The focus indication area has a contrast ratio of at least 3:1 against all adjacent colors for the minimum area or greater, or has a thickness of at least 2 CSS pixels.</li>
<li><strong>Unobscured:</strong> Unobscured: The item with focus is not entirely hidden by author-created content</li>
</ul>
<p class="note">A keyboard focus indicator which has a pattern or gradient may have parts that do not meet the 3:1 contrast ratio for the change of contrast, as long as an area equal to the minimum does meet the contrast ratio.</p>
<p class="note">If the control has a visible boundary smaller than the hit area, the size measure is taken from the visible boundary.</p>
Expand Down
7 changes: 7 additions & 0 deletions understanding/22/focus-visible-enhanced.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -25,6 +25,7 @@ <h2>Focus Visible (Enhanced) Success Criteria text</h2>
<li><strong>Minimum area:</strong> The <a>focus indication area</a> is greater than or equal to a 1 <a>CSS pixel</a> border of the focused control, or has a thickness of at least 8 CSS pixels along the shortest side of the element.</li>
<li><strong>Change of contrast:</strong> Color changes used to indicate focus have a contrast ratio of at least 3:1 with the colors changed from the unfocused control.</li>
<li><strong>Adjacent contrast:</strong> The focus indication area has a contrast ratio of at least 3:1 against all adjacent colors for the minimum area or greater, or has a thickness of at least 2 CSS pixels.</li>
<li><strong>Unobscured:</strong> Unobscured: The item with focus is not entirely hidden by author-created content</li>
</ul>
<p class="note">A keyboard focus indicator which has a pattern or gradient may have parts that do not meet the 3:1 contrast ratio for the change of contrast, as long as an area equal to the minimum does meet the contrast ratio.</p>
<p class="note">If the control has a visible boundary smaller than the hit area, the size measure is taken from the visible boundary.</p>
Expand Down Expand Up @@ -177,6 +178,12 @@ <h3>Adjacent contrast</h3>
<figcaption>Adding an outline that is separated from the button helps to differentiate which one is focused.</figcaption>
</figure>

</section>
<section id="unobscured">
<h3>Unobscured</h3>
<p>Where other content can overlap with a focused item, the focused element should not be hidden. Typical content which can overlap focused items are sticky footers, sticky headers, or non-modal dialogues. As a user tabs through the page, these layers of content can obscure the focused item, including the focus indicator.</p>
<p class="note">The criterion specifies the "focused item" in the unobscured bullet rather than the "focus indicator". The requirements for the indicator are set in the previous bullets, the unobscured bullet applies to the item as a whole.</p>

</section>
<section id="relation-non-text-color-contrast">
<h3>Relation to non-text color contrast</h3>
Expand Down

5 comments on commit bedbdda

@JAWS-test
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the purpose of "entirely"? I.e. if a small item is 1% visible, although 100% could be visible, the SC is fulfilled as long as the focus indicator fulfills the rest. This does not achieve anything, because if I see only 1% of the background but not the text label from a button - what then?

@detlevhfischer
Copy link
Contributor

@detlevhfischer detlevhfischer commented on bedbdda Jul 2, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JAWS-test What then? Then you have to scroll. You could argue that compared to seeing no focus at all, it is still better to know that there is something that is getting focused (even if you only see the top edge and have to scroll up to see what is focused).

What remains unclear from the current wording is if the general focus indication area requirement set out in the SC equally applies to situations where the element (and in turn usually the focus on it) is only partly visible. What percentage of the focus surface area is then still visible is likely to change depending on the viewport width, zoom state, and the browser you happen to use, so the only way I can think of to evaluate this consistently is to assume that in cases where the element is only partly visible, any visibility of the focus is sufficient to meet the SC (even a single pixel). If that is the intent, this should be made clearer in the note to "unobscured".

@JAWS-test
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@detlevhfischer As I mentioned several times in the discussion on this SC, there are many examples (even at W3C, e.g. https://w3c.github.io/aria-practices/examples/combobox/combobox-autocomplete-list.html) where the focused element is not visible and at the same time scrolling with the keyboard is not possible because the focused element is operated with the arrow keys (radio buttons, dropdown lists, grids, tabs, toolbars etc.)

@detlevhfischer
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JAWS-test IF bullet 4 is accepted, it might need a trailing condition like "AND focusable content dependent on the element can be brought into view via the keyboard after th eelement receives focus", or similar? Otherwise I only see the keyboard operation work-around of tabbing further (or back) to an element that does not consume arrow keys, change scroll status, tab back to element with arrow-focusable children, then use arrow keys...
What is your suggestion to solve this? Require that the entire element is visible when it receives focus? When the element is immediately above the lower bound of the viewport, could that not cause the same problem for pop-up content (like the tablist of a combobox?) Haven't tried, just wondering...

@JAWS-test
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@detlevhfischer

Otherwise I only see the keyboard operation work-around of tabbing further (or back) to an element that does not consume arrow keys, change scroll status, tab back to element with arrow-focusable children, then use arrow keys...

Unfortunately, this is not acceptable:

  • the page may not contain such elements with which the page can be scrolled
  • the page may contain fixed headers and footers, so that the method does not produce the desired result (if the focusable elements have a large distance)
  • the method means an extra effort and is a trick one must know. The WCAG-SC in its whole, however, aims exactly at not having to use such tricks and to avoid such additional effort

What is your suggestion to solve this?

My suggestion was:

  • SC, bullet 4: The focused element is in the visible area

The Understanding or SC also states

  • that the focus must also be visible to such an extent that the remaining focus requirements are still fulfilled (bullet 1-3)
  • that bullet 4 does not apply to browser errors (e.g. link URL hides focused element)
  • that for large elements that cannot be displayed completely, at least the beginning of the focused element (e.g. in our language area the upper left corner) is displayed

When the element is immediately above the lower bound of the viewport, could that not cause the same problem for pop-up content (like the tablist of a combobox?)

  • The SC does not require the element to be displayed at the bottom
  • I don't see a problem with tabs. For combo box: should behave like native select lists, i.e. the list entries are displayed above or when opening or using the arrow key navigation within the list, the page is scrolled accordingly. The only requirement would be that custom elements do not behave worse than HTML elements

Please sign in to comment.