Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve accessibility of open in new window toggle #2667

Closed
karmatosed opened this issue Sep 5, 2017 · 5 comments · Fixed by #3234
Closed

Improve accessibility of open in new window toggle #2667

karmatosed opened this issue Sep 5, 2017 · 5 comments · Fixed by #3234
Assignees
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Type] Bug An existing feature does not function as intended

Comments

@karmatosed
Copy link
Member

karmatosed commented Sep 5, 2017

[Edited by @afercia to report the right issues, sorry for the confusion]

Splitting this out from #2204 see also #2628

1
the "cog" button doesn't have any text or aria-label, it's completely empty so it will be reported by assistive technologies just as "button". Worth noting the other buttons that are very close in the code, they all have an aria-label...

Since it misses an aria-label, the button misses also a tooltip. I'd say it should have an aria-label with text "Link settings" or something along those lines.

screen shot 2017-09-05 at 16 06 11

2
z-index issue!
see screenshot above: when entering or pasting a link and there are also search results, when pressing the cog button the expanded panel stays below the search results.
To reproduce, insert a link to https://wordpress.org in a couple other posts. Then edit a third post and insert a link pasting in the field https://wordpress.org.
I'd say either increase the x-index or, maybe better, close the search suggestions when the setting panel is expanded, and display them again when the setting panel gets closed.

3
the input field misses a focus style.
This is because the input fields inherit the focus style from forms.css where input of type="url" aren't targeted. Two options here:

  • set the input field to type="text" and miss minor advantages given by type="url"
  • add proper selectors to the styles in core forms.css, targeting type="url"

4
IE 11 and Edge display a proprietary "X" control in the input fields of type="url":

ie11

edge

This would be a minor issue, but unfortunately the spinner that appears when the search runs doesn't look so nice in combination with the "X":

screenshot 62

If I remember correctly, a similar issue happened in the Customizer for the menu/widget search field and we just switched back the input field type "search" to "text" (which would also solve the focus style issue).

@karmatosed karmatosed added [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Type] Enhancement A suggestion for improvement. labels Sep 5, 2017
@notnownikki
Copy link
Member

I thought this had been done, can you let me know what wasn't there? There's an aria-expanded attribute that shows if the expanded div is expanded or not, as far as I can see...

@afercia
Copy link
Contributor

afercia commented Sep 5, 2017

Yeah, aria-expanded works well. Updated the issue description with some new things to address.

@notnownikki notnownikki self-assigned this Sep 6, 2017
@notnownikki
Copy link
Member

notnownikki commented Sep 6, 2017

I'm not sure what to do about point 4. If we change the input type from url to text, we lose the URL validation.

I believe that the following CSS:

.blocks-url-input {
	input[type=url] {
		&::-ms-clear {
			display: none;
		} 
	}
 }

would work, but I don't have access to all the browsers to test. Could someone verify for me?

@afercia
Copy link
Contributor

afercia commented Sep 6, 2017

Sorry I was wrong: IE 11 and Edge display the "X" also for normal fields of type "text" so yes, there's the need to hide it with CSS. @notnownikki I think that CSS is correct and also already used in the Customizer, see wp-admin/css/customize-controls.css

However, as I'm aware of, WordPress is not using anywhere the required HTML attribute thus it's not using browsers built-in validation. Until now. With the new browsers support policy, I think all supported browsers have some basic built-in validation. However, if Gutenberg is going to introduce this, I guess it's something that should be discussed during the main dev chat on Slack with the project leads, as it's a new relevant feature introduced in core.

Would be relying only on built-in browser validation be enough?
What about old browsers that users may still use?
Are there any security concerns?

I'd recommend to raise up this topic during dev chat. /cc @mtias @aduth

@afercia afercia added [Type] Bug An existing feature does not function as intended and removed [Type] Enhancement A suggestion for improvement. labels Sep 11, 2017
@afercia
Copy link
Contributor

afercia commented Sep 11, 2017

Sorry, changing Enhancement label to Bug because unlabeled UI controls are a bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants