Avoid italic text for better accessibility and readability

[afercia]

Follow up to an ongoing discussion on the Gutenberg GitHub repository, see ​https://github.com/WordPress/gutenberg/issues/15683.

There are many different forms of dyslexia and different people are affected to varying degrees. When it comes to forms of dyslexia related to visual processing, not all the reading disorders are triggered by the same causes.

This is really a field where there are no "truths" about what is good or bad. Even specialized studies disagree, but there's general consensus that the font used and its metrics have an impact on some reading disorders.

While the ideal solution would be allowing a complete customization of the font, a simple step to help users is to avoid italic text.

Does this means italics needs to be banned?

No, it doesn't. Italics needs to be avoided on whole sentences or large blocks of text. A judicious use of italics, bold, and other font variants to highlight important parts of a sentence can even help dyslexic users.

Better readability for all users

Use of italic text in WordPress has some historical reasons. Years ago, there was no great awareness of accessibility issues related to font styles. Also, computer screens were 14 or 15 inches: the rendered text was bigger and more readable. On modern displays, the average rendered text size is smaller than in the past. Smaller size and italic style makes text difficult to read for many users.

Besides users with dyslexia, avoiding italic helps also users with low vision, even the ones with moderate low vision or reading issues related to ageing. A bigger default font size in the admin pages would also definitely help. This should be evaluated holistically because of the global changes it would introduce and deserves to be discussed separately.

Proposal

In the WordPress admin, italic text is typically used for descriptions and help text. Sometimes also for other elements, for example:

• labels in the Quick Edit and Bulk Edit forms: this is also inconsistent with labels styling across the admin
• error details text in the new Recover Mode functionality

For all these cases, I'd like to propose to remove the italic style.

Future

As noted on ​https://github.com/WordPress/gutenberg/issues/15683 and ​https://github.com/WordPress/gutenberg/pull/15469, a better typographic system should establish clear hierarchy by other means: spacing, font size, font weight, etc.

Discussion is ongoing, and any contribution is very welcome.

References:

The WCAG 2.0 used to explicitly recommend avoiding italic text (couldn't find this specific point in WCAG 2.1)

Understanding Guideline 3.1: Make text content readable and understandable
​https://www.w3.org/TR/UNDERSTANDING-WCAG20/meaning.html

Avoiding chunks of italic text

Webaim recommendations for cognitive impairments and readability
​https://webaim.org/articles/evaluatingcognitive/#readability

Use stylistic differences to highlight important content, but do so conservatively
Use various stylistic elements (italics, bold, color, brief animation, or differently-styled content) to highlight important content. Overuse can result in the loss of differentiation. Do not use italics or bold on long sections of text. Avoid ALL CAPS.

[afercia]

Random examples of Italic text in the WordPress admin pages.

[birgire]

+1

Related #44621 (Privacy Policy guide)

[afercia]

Thanks @birgire. The Privacy Policy guide page is really a wall of hardly readable text 😞

[afercia]

Related: #42651

[SergeyBiryukov]

Replying to afercia:

In the WordPress admin, italic text is typically used for descriptions and help text. Sometimes also for other elements, for example:

• labels in the Quick Edit and Bulk Edit forms: this is also inconsistent with labels styling across the admin
• error details text in the new Recover Mode functionality

For all these cases, I'd like to propose to remove the italic style.

I agree. The italic style on file paths under "This plugin failed to load" message on the last screenshot looks especially weird to me.

[afercia]

More examples of large blocks of italic text (from the Media Editor page)

[melchoyce]

Replying to SergeyBiryukov:

Replying to afercia:

In the WordPress admin, italic text is typically used for descriptions and help text. Sometimes also for other elements, for example:

• labels in the Quick Edit and Bulk Edit forms: this is also inconsistent with labels styling across the admin
• error details text in the new Recover Mode functionality

For all these cases, I'd like to propose to remove the italic style.

I agree. The italic style on file paths under "This plugin failed to load" message on the last screenshot looks especially weird to me.

+1, these are super weird — I feel like we can go ahead and make these changes immediately.

re: the descriptions, I think in many cases italics are there for hierarchy. We'll want to explore alternate ways of establishing hierarchy in these cases. Going to discuss this in tomorrow's design meeting in Slack.

[afercia]

Thanks @melchoyce 👋 For what is worth, I do realize the importance of hierarchy and would love to see it better implemented holistically with a (finally) well established typographic system.

[afercia]

One ore screenshot: there are a few places where italic text is used together with a very small font size. Though the font-size in core is being discussed separately, very small font size values combined with italic make readability even worse. See for example the screenshot below: the actual font size is 11 pixels.

[birgire]

Here are two more examples:

The screenshot plugin-editor-italic.jpg​ shows the italic text when the file is not writable in the Plugin Editor or the Theme Editor.

I wonder though if this should be a notice instead.

It also shows the footer text.

The screenshot export-filtering.jpg​ shows the italic text under the Export filtering.

[afercia]

I think in many cases italics are there for hierarchy. We'll want to explore alternate ways of establishing hierarchy in these cases.

I do realize the importance of hierarchy and would love to see it better implemented holistically with a (finally) well established typographic system.

Noting there's now an official proposal to introduce better typographic hierarchy in core, see the related post on Make WordPress Design:

Proposal: a consistent type scale for WordPress
​https://make.wordpress.org/design/2019/10/11/proposal-a-consistent-type-scale-for-wordpress/

It would be great for the new type scale to explore new patterns for the descriptions so that italics can be removed.

[afercia]

Discussed during today's accessibility bug-scrub and agreed this ticket could be a work in progress with multiple commits that span over more than one release. Also, good ticket for a contributor day!

[estelaris]

At #design triage today we agreed on following up on this ticket and including it in @davewhitley’s Proposal: a consistent type scale for WordPress
​https://make.wordpress.org/design/2019/10/11/proposal-a-consistent-type-scale-for-wordpress/.

This is good work and like @afercia said, perhaps something that could be in small updates and extended to several releases.

[audrasjb]

Removing obviously useless italics as a first pass on 47327

[audrasjb]

Italics removed from quick edit labels

[audrasjb]

Italics removed from edit media screen

[audrasjb]

Hi,

In 47327.diff I removed useless italics from quick edit and media edit screens.

In my opinion, .description texts should be addressed in 5.4 instead of a point release. We could commit those changes in 47327.diff first in a point release as there is a consensus on how italics doesn't much sense in those places, then take time for .description design :-)

Cheers,
Jb

[sabernhardt]

@audrasjb When I applied the patch, it rejected the plugin error hunk (perhaps because I applied it to my 5.4 trunk installation).

I also checked on the #commentsdiv .comments-box thead td, because I didn't see a thead element in the Post editor's Comments meta box (Classic Editor) to verify the change there. The td cell(s) within the header probably contained a bulk edit checkbox and/or the number of selected comments at first. I can't find a current use of that (using WordPress.org), but I did locate a screenshot of how the Bulk Edit Mode has looked on WordPress.com:
​https://en.support.wordpress.com/manage-comments/#bulk-edit-mode
(There probably is no need to italicize that text anyway.)

If we choose to delay editing the table cell style, I still would like to prioritize removing italics from:

1. the plugin errors,
2. the quick edit labels, and
3. the image editor help content.

[audrasjb]

Moving this ticket to milestone 5.4 as it will need a consensus (and a commit action) on the proposed changes.

[xkon]

Adding a needs-refresh as the 47327.diff​ currently fails on some hunks while applying after checking this on today's #design triage :).

[audrasjb]

Patch refresh

[audrasjb]

@xkon thanks for the heads up! The patch is refreshed.

[nrqsnchz]

@audrasjb this change feels good. I keep wanting to still maintain some visual distinction or separation between the helper text and the labels:

@sabernhardt had a great suggestion during today's a11y bug scrub of adding a bit of space. It could look something like this:

[sabernhardt]

@nrqsnchz I was thinking of a smaller increase in the margin, roughly 5-10 pixels.

A change I considered last month was .imgedit-help {margin-bottom: 1em;}. This would give 5px more than the 8px top margin of the next element (at the default 13px font size). And when a user increases the minimum font size, the spacing increases with it.

If you want more spacing than that, however, a fixed pixel value (16-24?) probably would be more appropriate than ems.

[nrqsnchz]

Replying to sabernhardt:

A change I considered last month was .imgedit-help {margin-bottom: 1em;}.

I think I used 2em for the screenshot, but definitively is not a thorough test. I think you're right and 1em could work well.

[afercia]

Note: jQuery is known to not being able to animate margins very well. That is: it immediately removes the margin, then animates the inner height (padding + height) thus producing a visible "jump" at the beginning of the animation. I'd suggest to use a bottom padding instead, which jQuery can calculate and animate properly.

[SergeyBiryukov]

In 47147:

Accessibility: Privacy: Improve the readability of the suggested text in Privacy Policy Guide.

Per WCAG 2.0 guidelines, big chunks of italic text should be avoided for better accessibility.

Props birgire, sabernhardt, xkon, garrett-eclipse, melchoyce, karmatosed, afercia, jepperask, SergeyBiryukov.
Fixes #44621. See #47327.

[karmatosed]

Removing design keywords as this has feedback.

[sabernhardt]

For padding, I suggest .imgedit-help {padding-bottom: 8px;} because margin values for the other elements use 8px. That would make the spacing total 24 pixels for the Scale and Crop sections and 18 pixels for the Thumbnail section.

Or if 24 is too much, the spacing could total 18 pixels within each of the three sections with .imgedit-help {padding-bottom: 2px;} and p.imgedit-help {padding-bottom: 8px;}

[afercia]

47327.2.diff​

• Adds the 8 pixels bottom padding making sure to exclude the "Restore Original Image" box
• Changes the inline-edit-or text ("–OR–") displayed in the Quick Edit form from <em> to <span>: <em> is meant for semantic emphasis which is not appropriate in this case
• In the Image Editor: the Thumbnail Settings help was a <p> element while all the other ones are <div> wrapping a paragraph. This seems to be the case since its introduction in [11965]. Changed to a <div> that wraps a paragraph for consistency. Also, this way the jQuery animation runs on an element that has no top/bottom margins (while paragraphs inherit margins) so it runs without "jumpiness".

Looks good to me. Tested the Image Editor help also in the media modal.

When committing, please keep the ticket open as this is an in-progress work that will span across multiple releases.

[afercia]

To recap, 47327.2.diff​ removes italic text from:

• the Quick Edit / Bulk Edit forms
• the Recovery Mode plugin error details
• the Image Editor inline help
• re: #commentsdiv .comments-box thead th and #commentsdiv .comments-box thead td: they relate to the Comments meta box in the Edit Post screen but I couldn't find where these elements are supposed to appear. They were added in https://core.trac.wordpress.org/changeset/20164 for WordPress 3.4

[afercia]

In 47304:

Accessibility: Improve readability by removing unnecessary italic font style.

Per Web Content Accessibility Guidelines 2.0, big chunks of italic text should be avoided.
Same applies to UI controls, since they're meant to be comfortably readable by the largest possible audience, e.g.: label elements.

Removes italic font style from:

• the Quick Edit / Bulk Edit forms
• the Recovery Mode plugin error details
• the Image Editor inline help

Props birgire, audrasjb, SergeyBiryukov, melchoyce, estelaris, sabernhardt, xkon, nrqsnchz, afercia.
See #47327.

[afercia]

Moving to 5.5 as the work here will span over a few releases.

[azaozz]

Sorry but [47304] looks like another "out of bounds" commit. What part of [47304] fixed a bug introduced during the development of 5.4? Why should it be committed after the beta version was released? How was the committed code reviewed and tested?

True, it doesn't look like this commit can break styling like the CSS enhancements committed during 5.3 beta, but breaking the release cycle rules is a bad workflow nevertheless. This looks like a fix that should have been committed before the beta was released. Failure to review and commit it in time means it should go to the next milestone.

[afercia]

No objections to revert it.

It would be useful to make this ticket a task, I guess.

[audrasjb]

Before 47327.3.diff - Taxonomy lists screen

[audrasjb]

After 47327.3.diff - Taxonomy lists screen

[audrasjb]

Before 47327.3.diff - Menus screen

[audrasjb]

After 47327.3.diff - Menus screen

[audrasjb]

Before 47327.3.diff - Settings screens

[audrasjb]

After 47327.3.diff - Settings screens

[audrasjb]

Administration: Accessibility: Remove italics CSS font-style declarations from Taxonomies list screen, Menu screen and Settings screens

[audrasjb]

47327.3.diff is my suggested scope for WP 5.5.

Remove italics from the following screens:

• Taxonomies list screens
• Nav Menu screen
• Settings screens

[afercia]

47327.4.diff​ removes italic text from one more element; the "link-to-original" text in the Menus items details.

[afercia]

In 48116:

Accessibility: Improve readability by removing unnecessary italic font style.

Continues the removal of italic text where unnecessary or where used on whole lines and big chunks of text.
Removes italic type from:

• all the howto text e.g. the "Tags" meta box, the "Featured image" meta box, the "Insert/edit link" modal dialog in the Classic Editor
• the Taxonomies list pages
• the edit Taxonomies pages
• the Menus page
• the Settings pages

Props audrasjb.
See #47327.

[afercia]

I'd like to propose to include in the scope of WordPress 5.5 the "removed text" in the Privacy policy guide page.

When deactivating a plugin that provided a Policy page, the whole removed policy text is presented to users _all italic_. It's a huge chunk of italic text where readability is far from ideal. To reproduce:

• install and activate a plugin that provides a Privacy text e.g.: WooCommerce
• deactivate the plugin
• go to wp-admin/privacy-policy-guide.php
• after the WordPress related text, observe the huge block of italic text under "Source: WooCommerce"
• aside: I don't think the admin notice displayed there should be an "error" with a red border; also, the CSS class "error" is legacy and should not be used: notices class must be stacked with the base one e.g. notice notice-info
• see the attached screenshot of the huge block of text

This would be a one line change in edit.css, see the selector .text-removed .policy-text

[afercia]

47327.5.diff​ removes italic type from the "removed" policy text. Also, updates the "error" notice to notice notice-info (blue border).

[audrasjb]

Patch applies cleanly and solves the issue on my side. Marking this for commit

[afercia]

@garrett-eclipse 👋 pinging you as Privacy component maintainer. Would you like to mark the e "removed" policy text by any other means? We'd like to remove the italic type. See comments above.

[SergeyBiryukov]

In 48145:

Accessibility: Privacy: Improve the readability of the removed text in Privacy Policy Guide.

Per WCAG 2.0 guidelines, big chunks of italic text should be avoided for better accessibility.

Additionally, replace the legacy .error class for "You deactivated this plugin and may no longer need this policy" message with .notice-info.

Follow-up to [47147], [48116].

Props afercia, audrasjb.
See #47327, #44621.

[afercia]

In 48281:

Accessibility: Plugins: Accessibility and CSS improvements for the Plugins pages.

• improves checkboxes alignment on the "Plugins" page table in the responsive view
• improves spacing between form controls on the "Add Plugins" page in the responsive view
• the layout of the "filter bar" on the "Add Plugins" page is now based on CSS Flexbox
• removes italic type from a paragraph in the "Favorites" page

Props passoniate, garethgillman, maxpertici, audrasjb, sabernhardt, afercia.
See #47327.
Fixes #49231.

[afercia]

Note for triage: the 5.5 scope of this task is completed. Can be moved to 5.6 :)

[afercia]

Moving to the 5.6 as this is a task that will span across multiple release cycles.

[garrett-eclipse]

Replying to afercia:

@garrett-eclipse 👋 pinging you as Privacy component maintainer. Would you like to mark the e "removed" policy text by any other means? We'd like to remove the italic type. See comments above.

Sorry I missed your ping @afercia I'm all for it. Looking at commit [48145] it seems to have been removed so that's great.

Looking at the current state it is now hard to discern what's removed so I'll look into that separately here for 5.6, opened #51435 for it. And will definitely avoid italics ;)

[afercia]

Thanks @garrett-eclipse :)

[garrett-eclipse]

@afercia I applied two potential patches to #51435 if you have any thoughts they're always welcome.

[afercia]

@garrett-eclipse thanks!

As there are no changs for the 5.6 release, the accessibility team agreed during last weekly meeting to move this ticket to the next release cycle to continue the work there.

[ryokuhi]

The ticket was discussed today during the weekly accessibility bug-scrub.
At the moment, it needs some screenshoots and documentation of remaining italics instances.
According to @joedolson, most of what is left looks like notices displayed only in very specific situations (missing PHP support, for example), so finding all instances might require a a bit of work.
After that, the actual patch creation will probably be pretty easy.

[audrasjb]

Remove useless italic: WP 5.7 edition

[audrasjb]

Hi there,

Remove useless italic: WP 5.7 edition: to me, those strings use really useless italics, via the semantic element <em>. In my opinion, those <em> tags can be removed without risk in WordPress 5.7.

[audrasjb]

Oops, thanks @xkon who noticed that my previous patch removes some lines from phpunit testing.
Adding a new version right now.

[audrasjb]

Patch refresh

[audrasjb]

OK given no other change was proposed, I'd propose to commit the above changes for 5.7.
Also, given we addressed most of the admin issues, I'd lean towards closing this task and open ad hoc tickets for the remaining issues in the future.

What's your opinion on this @ryokuhi?

[joedolson]

In 50032:

Administration: Remove italic text to improve readability.

Italicized text can be difficult to read for some people with dyslexia or related forms of reading disorders. This removes italics on a number of larger blocks onpm run grunt rpf text in the admin. This has been a task 5.3; this commit closes the task. Further instances of italicized text should be addressed individually.

Props afercia, xkon, audrasjb
Fixes #47327