Focus indicators for large editing areas

[alastc]

In #1930 @mbgower wrote:

In the 4th bullet of the Typical focus indicators list ( ⅓ through Understanding), it addresses insertion points. It got me wondering about something - whether we should have language about text editors (think of code editors) where the insertion point is the ONLY form of focus indicator. Maybe such an interface isn’t a UIC? Should that be noted?

I wanted to separate this off into it's own issue.

I wonder if we need a similar concept to target-size where an interactive area (whether rich-text editor or colour selector) is not in itself a discrete control?

If I'm in a code editor like MS Code, an outline around the whole editing area is not particularly useful or desirable. However, for most text inputs, it is necessary.

Is there a line we can draw there? E.g. a rich-text or code editor isn't itself a UIC, but a combination of UICs.

[mraccess77]

Platforms like Windows now have features to highlight carets with triangles and colors which helps to mitigate this issue.

[alastc]

@mraccess77 that's useful to know, but would you consider that sufficient for all types of text input?

I had thought that for regular (1-line) text inputs a focus indicator around the whole thing would be one of the main benefits for this SC?

However, when it gets to multi-line (therefore large areas that could require a massive indicator), and that indicator may not be very useful due to being wrapped around a large area. (E.g. most of it might be off-screen.)

[anevins12]

Is the comment box on this thread a good example of a large multiline text input? As a new Windows Magnifier user, I've learnt that zooming out entirely (like ctrl + alt + space) can help people find what they're looking at. A similar shortcut exists in ZoomText. If people are familiar with that shortcut then a focus ring around the whole multiline text input at a minimum could still work. Then again, as we're not relying on assistive tech to follow caret focus (which screen magnifiers can do too), maybe it's best that I don't assume users will be using them.

[mraccess77]

@anevins12 Github's text areas are similar - but may not be as large as an area like VS Code, notepad, or MS Word. For the comment fields in Github I also find the border helpful and a large indicator should apply in my opinion.

I think where it may not be as necessary would be when the field takes up the entire screen like in a code editor or notepad. So when the field takes up x% of the viewport or something like that then the border might not be as obvious and maybe something else might be more helpful. At that point finding the caret itself might actually more important.

[mraccess77]

@alastc yes, borders around 1 line and even larger text areas is helpful. It's when they take up most of the screen when it's probably not as useful.

[rainbreaw]

Even when the eding area takes up the entire viewport, it would help users to have a visual indication of when they are focused inside the edit area and editing, vs. focused on a control for formatting or something else. I recognize that this isn't standard in document editing interfaces, and people are familiar with it as is. It would help users, however, to have a clearer indication if pressing a key will enter text in or impact the text area, or if it will do something else (like change formatting or continue a comment thread).

[patrickhlauke]

Even when the eding area takes up the entire viewport, it would help users to have a visual indication of when they are focused inside the edit area and editing, vs. focused on a control for formatting or something else. I recognize that this isn't standard in document editing interfaces, and people are familiar with it as is. It would help users, however, to have a clearer indication if pressing a key will enter text in or impact the text area, or if it will do something else (like change formatting or continue a comment thread).

currently, that's what things like the cursor/caret intend to do. and these can't be explicitly styled if using something standard like <textarea> or a container forced to be contenteditable. it will be tricky to mandate that authors create some form of completely custom indicator of this kind.

[alastc]

Customising the cursor / caret isn't on the table at the moment, the question is whether we create an exception for large / multiline text input.

[patrickhlauke]

Sorry yes, my above was intended as "...which is why an exception may be the most realistic option..."

[DavidMacDonald]

  Is a multi-line editing area a “user interface component”?

I would say yes. I think for simplicity that we would just require the same focus requirements on that large component, understanding that it might or might not be useful... users of magnifiers might not get much value out of it, but there are controls to bump up the caret in most magnifying AT.

I'm not keen on making the SC more complicated for an edge case... I would say it's already the most complicated SC in the history of WCAG since 1998.

[alastc]

I'm not keen on making the SC more complicated for an edge case... I would say it's already the most complicated SC in the history of WCAG since 1998.

I'm not keen on making it more complex either. However, I'd say that info & relationships is more complex in practice as it's so wide-ranging. Still, that's probably a good conversation to have a in a bar!

[bruce-usab]

I agree that a multi-line editing area is a UIC. I agree that, at certain size threshold, giving those UIC a focus indicators a focus indicator becomes useless, and maybe even counterproductive.

Did we already kick-around an exception for UIC with more than one line of text or a UIC taking up more than X% of viewport?

Please remind me, what requirement do we have a requirement for enhanced text insertion point (caret, cursor)?

[patrickhlauke]

do we have a requirement for enhanced text insertion point (caret, cursor)?

as to my knowledge that's fully out of the control of the author, and left up to the platform/browser, i hope not...

[bruce-usab]

Reading more carefully, I find that @alastc notes that customizing the cursor / caret isn't on the table at the moment.

I like @mraccess77 idea that we add an exception for a UIC taking up more than X% of viewport. I'll take the liberty to suggest 50% as the threshold. It seems to me that situations where the UIC focus is useless/counterproductive, the editing portion of the window is probably approaching 90%.

[patrickhlauke]

I like @mraccess77 idea that we add an exception for a UIC taking up more than X% of viewport. I'll take the liberty to suggest 50% as the threshold.

the viewport size will vary though depending on browser window size, zoom, etc. not something that can be pinned down (or you get into the whole discussion of defining minimum/maximum sizes to consider for testing, as otherwise it's infinite possible combinations)

[alastc]

I know I opened this issue, but I feel like an agreed response is appropriate:

---

Whilst there are circumstances where a large editing area may not need a proportionally large focus indicator, it may still be beneficial to some. It would also add more complexity to an already complex criterion.

Therefore the group does not wish to differentiate large editing areas for the purpose of focus-appearance.

[mraccess77]

I agree with the response to keep the requirement for large editable areas.

[patrickhlauke]

+1

[mbgower]

That's fine with me. I would ask that text areas be considered as part of the Understanding document. The issue can be closed from my perspective.

[alastc]

From the meeting today, the group thought there are scenarios where it shouldn't apply, but those aren't in scope anyway. We need to update the understanding doc with info on that.

Something like:

---

Large editing areas such as code-editors, graphics editors, and other interfaces with a canvas with multiple functions do not fit into the scope of "user-interface controls".

[bruce-usab]

I am okay with the proposal above. That said, would either of these two approaches be less ambiguous than having to use large editing area?

• This SC applies to the inner-most UCI. or
• This SC is not applicable to UCI which contain other UCI.

[mraccess77]

I we went with "This SC is not applicable to UCI which contain other UCI." then it would mean that list boxes would not need an outer focus indicator and only the focused option would need an indicator. I would prefer to have a more clear indicator where the listbox itself appeared focused.

[mbgower]

@alastc I thought I created a rewrite that explained this in regard to UIC, but cannot locate it. I will try to remember what I constructed and create a mod of your branch.

[mbgower]

@alastc I have created a branch off your branch #2111

[rachaelbradley]

@awkawk We have previously discussed that providing persistently visible, relevant instruction is considered a sufficient technique that meets the need for "information needed to identify that user interface component." If we add a technique and text to the understanding that makes this clearer, would that address Adobe's concern? Instruction text could be added near the canvas that would persist if desired or removed if a user doesn't need it.