Inaccessible input for link's URL

[Comandeer]

Is this a bug report or feature request? (choose one)

🐞 Bug report

💻 Version of CKEditor

Version from docs.

📋 Steps to reproduce

1. Select some text.
2. Click link button.

✅ Expected result

Shown input has proper label that is announced by screen reader.

❎ Actual result

Only [placeholder] value is announced by VoiceOver, which is confusing as placeholder is set to a URL.

Chrome devtools Accessibility Inspector shows that current label is empty:

📃 Other details that might be useful

The issue is caused by the fact that label for the input is hidden with display: none. It should be hidden with more accessible technique, e.g. one proposed by H5BP.

In the ideal situation, link dialog would display both label and hint outside the input itself:

If the hint is present, then it should be bound to the input with [aria-describedby] attribute.

Some context:

• https://www.smashingmagazine.com/2018/06/placeholder-attribute/
• https://www.filamentgroup.com/lab/a11y-form-labels.html
• https://www.scottohara.me/blog/2018/05/24/keep-labels-clean.html

[Reinmar]

cc @oleq @dkonopka

[oleq]

I check this out and simply adding aria-hidden="false" to the <label> fixed the issue in VoiceOver. Can you confirm this is an acceptable approach, @Comandeer? Because it's the simplest one I could think of.

[Comandeer]

Well, it fixes issue for users of screen readers, but all other concerns (described in linked articles) are still there.

[oleq]

but all other concerns (described in linked articles) are still there.

If you mean concerns about discoverability (placeholder disappears when the user is typing), we discussed that during the design phase and dismissed it because there's no way this form could surprise anyone; it's either:

• displayed after the user clicked the link button in the toolbar,
• displayed after the user clicked a link, and then decided to edit it

Besides, even FB uses placeholders for their sign up form ;-)

Anyway, we decided to take some risks to gain a more compact and modern-looking UI. And mostly we were aware of them. Still if we

• make sure the inputs placeholders pass WCAG AA (they do),
• (TODO) unblock the labels,
• (TODO) and provide an additional description using aria-describedby

then, I think, we're on the safe side, despite other potential concerns.

[Comandeer]

Besides, even FB uses placeholders for their sign up form ;-)

And that's a part of why FB is not considered super accessible :P

make sure the inputs placeholders pass WCAG AA (they do)

In such case placeholder could be mistaken with filled field (I have issues with distinguishing between them).

But yes, making label visible for screen readers and adding the description (however this description will be available only for screen-readers users – and it could be helpful for anyone) should fix the biggest issue with this input.

[oleq]

I'll create a simple PR for this issue.

[Comandeer]

The same situation (incorrect label) is present also for other inputs in the editor, e.g. media embed one.

[Comandeer]

Some more context: https://codepen.io/stevef/post/placeholder-the-piss-take-label#show-us-the-fail-they-ask-1

This indicates that label should be visible the whole time.

[mlewand]

I believe ideal solution to that is a label, that is shown the way placeholders are (so inside the input but is distinguishable from a user provided text with styling) and as user provides input the label shrinks and move to the top of the input, kind of overlapping with its boundaries.

[oleq]

As in https://material.io/design/components/text-fields.html#outlined-text-field?

[mlewand]

@oleq yes, that's exactly what's on my mind.

[oleq]

I created a PoC with the "material approach". The only drawback (so far) I see now is that we're gonna need more padding around forms so balloons like link or text alternative will be bigger.

The code:

• https://github.com/ckeditor/ckeditor5-theme-lark/compare/t/ckeditor5/1098-poc?expand=1
• https://github.com/ckeditor/ckeditor5-ui/compare/t/ckeditor5/1098-poc?expand=1

[mlewand]

@oleq looks nice to me. Any reason why you dropped a thicker outline upon focus?

Now it looks inconsistent with buttons next to it, buttons in the toolbar etc.

[oleq]

@mlewand Doesn't look good with the notch IMO

But maybe it needs some polishing.

[Reinmar]

I had to compare your proposal with what we have right now, to realise that what we currently see is:

So, there will be one more change – the placeholder (usually – an URL) will be replaced with a label.

Which makes the description in media embed dialog unnecessary:

Which causes a problem with the fact that now it can be seamlessly replaced with this tip:

BTW, I think that the code that you pushed (the two branches) don't work:

I guess more changes are needed than just in the UI and theme packages.

[oleq]

The code is incomplete. You have to increase the padding of the balloons manually. And I didn't even consider the media balloon; it's a PoC after all.

[Reinmar]

Regarding issues that you were discussing here:

• The bigger padding... I think we can't avoid that if we want that label somewhere. If we'll have the label above the input (classical approach), then we'd have a vertically unsymmetrical form for the link. Using the material design approach will allow us to keep it symmetrical, which is fine.

• I'd consider a slightly bigger height of URL input – the text is a bit too close to the label. Perhaps something like (I added 3px there):

  

  I think it composes well with the bigger balloon padding.

• I'd do our best to try to keep our current focus ring. I personally really like it. And it'd be good if we could have it consistent with the rest of the buttons. Unfortunately, I can't test myself how would that work (your screenshot doesn't show the input border which is present on current master) because I can't find where it's defined 😅

[oleq]

• I'd consider a slightly bigger height of URL input – the text is a bit too close to the label. Perhaps something like (I added 3px there):

It's a bummer then 😕 The height of the input is in sync with the height of toolbar buttons. Increasing the height of the input will bloat toolbars. It's a weird and complex thing because it's a part of the UI scalability using variables system etc..

[Reinmar]

Doh, I didn't think about this. So, the only way around would be to move the label a few px higher, so it leaves enough space for the text inside the input. Which means that the balloon's padding would need to be increased (perhaps even more than you proposed).

IDK... it's hard to be happy about such a change because visually it's definitely for worse :D Maybe we just need a more concrete proposal (something that we can really test), agree to what we can improve in it and just accept it as it is.

Unless anyone have a better idea?

[oleq]

What exactly is wrong with https://github.com/ckeditor/ckeditor5/issues/1098#issuecomment-511868090? I don't think the distance between the label (inside the notch) and the input text is an issue here.

[Reinmar]

A little crowdy for me. And I find the inconsistency in input vs button's outlines disturbing. The former is not a blocker for sure, but IDK about the latter. In fact, is such a focus style accessible? Because we only change the color of the border. We also move the label, but IDK if that can be considered an "enough" solution.

[oleq]

👉 Live demo with the PoC 👈

It includes the latest code with changes in ckeditor5-link, ckeditor5-media-embed, and ckeditor5-image.

If you'd like this PoC, add a 👍 reaction to this post. If you find any issues or suggestions, please add a comment with your feedback in this issue.

---

Concerns and TODOs

1. If we went with the design in the PoC (or similar), what impact would it have on Letters/Cloud features? cc @pjasiun @oskarwrobel
2. Maybe the new design should be a separate ckeditor5-ui component?
   1. OTOH, what's the point of making things accessible when we leave an inaccessible component in our codebase?
   2. OTTH, this will definitely be a breaking change and it could seriously affect 3rd–party integrations. Can we do anything about it?
3. I removed input placeholders to have a large label when the user uses the feature for the first time (e.g. inserting a new link). Was that a good decision?
4. Related to the above, we should probably figure new helper text for the media embed panel.
5. We need to double-check if the contrast of labels in all their states matches WCAG standards.
6. What does the small label in the notch look like in LoDPI?

---

If you want to play with the code, use the "constellation branch" I prepared.

[Reinmar]

I think I like it, but I looked too many times and saw too many versions of it so I'm not sure about anything right now.

Some minor things:

• Blurred input with text inside:

  

• When you open a new link balloon, you can see the label moving because the input gets the focus at the same time. I wonder if that's fine or not.

• It doesn't look like a placeholder. I think it should be greyish.

• I removed input placeholders to have a large label when the user uses the feature for the first time (e.g. inserting a new link). Was that a good decision?

  👍

• What does the small label in the notch look like in LoDPI?

  Just fine:

• Related to the above, we should probably figure new helper text for the media embed panel.

  Hmm... I didn't initially notice that it doesn't make sense and I forgot I commented about this already. But yeah, you're right. A better helper text would be needed, although I guess no one would complain if we kept this one.

  Idea: show the hint about pasting URLs from the beginning?

• One idea – show more of the outline to align it with the padding inside the input:

  

[oskarwrobel]

If we went with the design in the PoC (or similar), what impact would it have on Letters/Cloud features? cc @pjasiun @oskarwrobel

No worries, In the worst scenario, we will need just to adjust some styles.

[dkonopka]

Just to add, I'd consider a slower label/placeholder movement animation (from .1s to .2s) - it's simply too fast. Additionally, it will be unified with buttons where we are using 200ms in the focus state. Besides that, it looks cool, gj!

[mlewand]

IMHO the proposal looks great. The thick border looks fine.

• It doesn't look like a placeholder. I think it should be greyish.

👍

@dkonopka when reading slower movement proposal I sounded like I want to second to slower transition. But once I applied it, .2 and .1 make a perceivable difference. Actually .1 feels much more zippy and smooth. .2 while allows you to better see what's happening, it might be annoying in a long run. And let's not forget this is just an eye-candy, the most important thing is that the end user can effectively use the field and finish the job.

[dkonopka]

@mlewand Ok, TBH I didn't check material design guides and as I can see they are recommending 100ms for small UI elements ( switches, checkboxes ) - https://material.io/design/motion/speed.html#duration.

However, what's interesting they are using 150ms for text field label: https://material.io/design/components/text-fields.html.

In my opinion, if we are implementing material.io based design, we should follow the animation property too - I mean 150ms.

[mlewand]

Since we have already put some real work into this issue, it would be nice to add finishing touches and close the feature. So I'm moving this into next milestone, hopefully we'll be able to tackle it in future iterations.

[Reinmar]

Agree. And perhaps we can count on some feedback if we link to this from the milestone ticket. Because we tried to gather some feedback, but there wasn't any so far.

[Reinmar]

@oleq Could you refresh the constellation of branches? I tried to merge master to those branches but there are some conflicts.

[oleq]

It's done. Check out https://github.com/ckeditor/ckeditor5/tree/t/ckeditor5/1098-poc for the latest version.

[oleq]

I revived the PoC in #7952 (migrated to monorepo, migrated table forms) and I think it's time to think it over, hence this RFC.

👉 Here you can check out the latest PoC with the new features live 👈

---

Context and Problem Statement

As @Comandeer pointed out in his original issue, inputs displayed in the UI of the editor (e.g. link URL, etc.) are inaccessible. There are 2 problems with the current approach:

1. screen readers don't read those fields properly because we hide their labels (display: none),
   • using aria-hidden="false" for labels could address this issue,
2. when a field contains some text the placeholder disappears and because the label is hidden as well there is no way to tell the purpose of the field (check out the screenshot below: what does the balloon do?)

Back in 2019, I came up with a proposal that implements material design–like inputs in CKEditor 5 to address both problems.

The PoC was forgotten 😕 because there were different priorities back then but now I decided to revisit it and see how it performs with new forms like table properties or table cell properties.

Decision Drivers

• Editor UI fields are inaccessible to screen readers,
• Editor UI fields are inaccessible to regular users, they might be confusing in some cases,
• Editor UI fields look dated (debatable).

Considered Options

Do "next to nothing"

• Use aria-hidden="false" for labels to address the issue with screen readers because it is a cheap fix (1st problem)
• Ignore the second problem, we've been living like this for years.

Display labels next to fields.

We could enable the labels before fields (they are already in DOM, it's just a matter of removing display: none):

Note: It does not change the look of table forms as the labels are already there under the fields (or before them when there is enough space).

Adopt the material UI approach

Check out the live demo. 

The idea is to adopt the Material approach to text fields but in a slightly more compact way because space our UI can use is very limited. In this approach, labels are always visible but there is little to no sacrifice in terms of space or layout.

Pros and Cons of the Options

Do "next to nothing"

Pros

• 👍 very quick: it will take just a few hours to finish, it's all about the ARIA attribute,

Cons

• 👎 it solves only 50% of our problems, it does not solve the second issue (the label-less fields are confusing)

Display labels next to fields.

Pros

• 👍 it solves both problems,

Cons

• 👎 it mangles the layout and the symmetry of some forms, for instance, link form or text alternative form,
  • the whole idea was these forms remain compact and linear (buttons perfectly aligned with the input),
• 👎 since the label always precedes (or follows) the input, some forms will consume more space,
• 👎 this may mean some changes in the UI of CF (provided it uses the LabeledFormView component), either the project will also change the approach or it will need to add the display: none for labels back

Adopt the material UI approach

Pros

• 👍 it solves both problems,
• 👍 it looks modern (debatable),
• 👍 it requires minimal space overflow (when compared to the 2nd option),

Cons

• 👎 it brings a considerable amount of new code to the project,
• 👎 it increases the complexity of components (for instance, new data bindings were necessary to implement this, not just CSS),
• 👎 it may give an impression of chaos because there's a lot going on (animations, labels moving around)
• 👎 it may require some actions in CF (provided it uses the LabeledFormView component),
  • on the second though, whether it uses the component or not, it would be great if UIs of both projects were consistent so this may require some refactoring in CF after all

[niegowski]

I really like the material UI approach with a few comments:

• Table properties and Cell properties balloons:
  • Both are smaller in height but they give the first impression of being crowded.
  • "Background color" should not be grouped together with "Border". This way it looks inconsistent and if the group label would be there it would add some space for more readability. Also missing the "Background" group label makes rows of fields spread inconsistent.
• Table properties balloon:
  • "Dimensions" and "Alignment" labels are vertically not aligned.
• Cell properties balloon:
  • "Table cell text alignment" breaks vertical spacings (other group labels have bigger spacings from fields).
• Some labels seem to be cropped (like "Height", "Padding" on the images below).
• On some small forms transitions of label behave differently on form appearing (for the same form animation is visible but after reopening of the same form there is no animation). Also, it makes it feel "woo what just happened". I think that labels should not animate on the form appearing (only as of the transition for focus).

[mlewand]

For me, I sad it once, I say it again: I really like the idea of introducing this material ui concept. I also like the way you implemented it 👍👍👍

I'm all for it as it is IMHO the best of all the solutions. We also already invested quite some time, so it makes sense to convert this into a tangible value in CKE5.

I also recall that we explicitly asked for community feedback back in iteration 29. We did not get any objections to the proposal, so we can see that there are objections out there.

Few minor details:

• The focus (border) animation is too slow. The text transition speed is fine 👌
• Given recent changes in image plugin dropdown, it looks really messy and crowded now (especially with this change):

I think it make sense to extract such details as a followup not to stop this big change.

[Reinmar]

A ready PR with screenshots landed in #8267.