Feature request: Display outlines only at keyboard interaction

[boghyon]

OpenUI5 version

All

Browser/version (+device/version)

• Desktop, Windows 10 (ver. 1607)
• Chrome 55.0.2883.87 m (64-bit)

URL (minimal example if possible)

https://openui5.hana.ondemand.com/#/entity/sap.m.IconTabBar/sample/sap.m.sample.IconTabBar

Any other information? (attach screenshot if possible)

This feature request may be controversial, but IMHO it is aesthetically unappealing to see those dotted lines every time wherever I click. This unfortunately encourages app developers to remove the focus ring completely. ^{[1] [2] [3] [4]}

It would be nice, if outlines are shown only when the user presses certain keys (like tab, arrows, etc.), and are hidden again when the user interacts with a mouse. I am not asking for complete removal of the focus indication. I hope this feature request is not against some a11y standards.

Thank you.

---

Edit: fixed broken screenshot link, added questions people attempting to remove the focus ring completely.

[vladimir-velinov]

Hi,

I understand your need, but this really goes against accessibility standards. In general the focus must be visible(determinable) without user interaction.
If for instance, you have multiple inputs (or interactive elements) you wouldn't know which is the focused one, right?

On that ground I would reject the request here.
p.s. without any recommendation here, but you could have a look at this post and see if you can't workaround it in your case

cheers
Vladimir Velinov(OpenUI5)

[hristop]

Hi,

As per the comment abnove, I am closing this issue.

Best Regards,

Hristo

[boghyon]

@vladimir-velinov: Thank you for the answer. Yes, I agree that the outline should be always visible for inputs. Apart from that, and also apart from the outline being displayed on the first focusable element when the page is ready, I request again to consider to:

• Hide the outline when the user interacts via a mouse
• Display on any focusable element when a keyboard is used (as usual)
• All of this except for input-based controls which should have the outline always displayed on focus, no matter which type of interaction.

This is typically how most browsers handle the outline on "native" HTML elements which can be tested here. Chrome on Windows, for example, when interacted via a mouse, doesn't display the outline on "native" buttons, radios, checkboxes, etc., whereas the outline is always shown on select and input elements.

I'd propose to adopt browser's heuristic by making use of focus-ring focus-visible (renamed) when it comes to displaying the outline. This would also improve consistency across web pages. I certainly fail to see how displaying an outline on a just-pressed-button gives any a11y value to a mouse user.

The basic polyfill for focus-ring from WICG explains the issue further and also why focus-ring was introduced in the first place.

@robdodson also explains it nicely in this video: https://youtu.be/ilj2P5-5CjI

[jmorino]

I agree with @boghyon on the idea. Maybe a better/nicer/more discrete/less invasive implementation would be acceptable ?

[boghyon]

In general the focus must be visible(determinable) without user interaction.

Actually, I'm curious which part of a11y standards supports the above requirement, or that focus indicator needs to be visualized also in pointer mode (mouse or finger).

Just went through various WCAG 2.x success criteria but couldn't find any statements that hiding the focus indicator in pointer mode (not completely, as described in #1289 (comment)) would fail the success criterion.^[1] And afaik, other standards such as VPAT or BITV base on WCAG as well when it comes to web content.

If it's not clearly defined by any standards, wouldn't it be acceptable to make the current behavior optional while adapting UA's behavior as default?

---

Also worth reading:

• WICG discussion about having different focus indicator behavior for mouse and keyboard users
• Explainer for the upcoming :focus-visible

[boghyon]

If anyone is interested: UI5 Web Components will look into the idea of adopting the :focus-visible specification. SAP/ui5-webcomponents#3986 (comment)