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)?