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

italics, bold, underline #50

Closed
shawna-slh opened this issue Apr 6, 2016 · 15 comments
Closed

italics, bold, underline #50

shawna-slh opened this issue Apr 6, 2016 · 15 comments

Comments

@shawna-slh
Copy link
Collaborator

From 6 April telecon (after item 7) (spurred by Issue #41)

We need to rethink this issue overall, including what we say in

@allanj-uaag
Copy link
Contributor

from: https://lists.w3.org/Archives/Public/public-low-vision-comments/2016JanMar/0005.html

Would it be useful to include the option of setting the colour of links / interactive text? These may not be discernable if their colour cannot be adapted to chosen bg colour,

Similar to Issue #53

@WayneEDick
Copy link
Contributor

Visual semantics are important for reading. Italics are not a good way to implement visual semantics for some users but they are good for understanding the context of text.
How can this be addressed.
There are a few ways:
Each time italics are encountered replace them with another typographic choice. I just substitute the italics wit "Comic Sans MS". Its curvy and with vertical space. The curvy of italic doesn't both it is the slanting of the white space.
Here are the needs:

  1. Users need to avoid styles with known problems like italics. We should discourage the use of italics for decoration.
  2. Users need typographic changes to recognize a change in semnatic context for a region of text. That is they need the same functionality italics use when they convey meaning.

@allanj-uaag
Copy link
Contributor

We already have 3.3.2 "Need to change font " , 3.1.3 Color, and 3.5.1 ability to configure elements. we can tell the author to avoid italics (or whatever). However, it would be better to allow the user to control what is displayed. We have many granular requirements. The document when taken as a whole says (to me) that the user needs to be able to control/configure/override the web content displayed. Italic, visited and unvisited link color, and other issues are even more granular. Do they need to be called out? Perhaps. In techniques or introductory material. I don't think they need a requirement. They seem to be covered by 3.1.3, 3.3.2, and 3.5.1.

@shawna-slh
Copy link
Collaborator Author

Currently:

3.3.3 Style
For some people, it is difficult to read blocks of text that is all italicized or underlined. For some people, bold text is easier to read.
User Need - Style: Users can change the text style (underline, italic, bold) of blocks of text.

Suggest: Add definition of "blocks of text" (from WCAG). Add note something like "(This applies to blocks of text, not individual words or phrases.)":

3.3.3 Style
For some people, it is difficult to read blocks of text [link to def] that is all italicized or underlined. For some people, bold text is easier to read. (This applies to blocks of text, not individual words or phrases.)
User Need - Style: Users can change the text style (underline, italic, bold) of blocks of text.

Currently:

3.5.1 Element-level Customization
Some people change the way certain elements are displayed to make it easier to distinguish types of text, such as headings. If all text is increased proportionally, headings can become very large and bigger than people need to read the main body text. So some people prefer for headings to be smaller and they use styling such as font, color, and indentation to distinguish heading levels.

Suggest: Expand this to clearly cover things like links, em, strong, etc.

Thoughts on how we want to expand this? Ideas for wording?

@lauracarlson
Copy link
Contributor

For 3.5.1 Element-level Customization, maybe consider adding something like the following after "Some people change the way certain elements are displayed to make it easier to distinguish types of text." and before the "If all text is increased proportionally..." bit that details how headings can be customized.

When markup is used according to specification, it provides semantic meaning. This in turn helps a person set a customized visual presentation for headings and links, as well as <strong>, <em>, <cite>, and other elements.

@allanj-uaag
Copy link
Contributor

merged Shawn and Laura

3.5.1 Element-level Customization
Some people change the way certain elements are displayed to make it easier to distinguish types of text, such as headings. When markup is used according to specification, it provides semantic meaning. This in turn helps a person set a customized visual presentation for headings and links, as well as , , , and other elements. If all text is increased proportionally, headings can become very large and bigger than people need to read the main body text. So some people prefer for headings to be smaller and they use styling such as font, color, and indentation to distinguish heading levels.

Perhaps change the last sentence to be

So some people prefer for headings to be the same size as paragraph text. They use styling such as font, color, and indentation to distinguish heading levels and other semantics.

@allanj-uaag
Copy link
Contributor

@allanj-uaag
Copy link
Contributor

new wording
3.3.3 For some people, it is difficult to read blocks of text [link to def] that is all italicized or underlined. For some people, substituting bold text or a different font for italics is easier to read. This applies to blocks of text, not individual words or phrases.

@shawna-slh
Copy link
Collaborator Author

shawna-slh commented May 26, 2016

Sorry I missed the meeting where this was discussed. For 3.3.3, I think we want to keep it simple and follow the pattern that we have throughout that section — that is, the first two sentences explain the reason behind user need — and not add information about "substituting" style or using different font for italics. I think that applies more to Element-level Customization, and I suggest we add a pointer to that. So I propose we leave the first part as is, and add a second paragraph:

3.3.3 Style
For some people, it is difficult to read text that is all italicized or underlined. For some people, bold text is easier to read.

This user need applies to blocks of text, not individual words or phrases. A related user need is Element-level Customization.

User Need - Style: Users can change the text style (underline, italic, bold) of blocks of text.

@shawna-slh
Copy link
Collaborator Author

For 3.5.1 Element-level Customization, there are several issues here and I think we want to address them in separate paragraphs. Proposal:

Some people change the way certain elements are displayed to make it easier to read and to distinguish types of text, such as headings, lists, links, strong, em, cite, etc.

Headings: If all text is increased proportionally, headings can become very large and bigger than people need to read the main body text. Some people prefer for headings to be smaller, and they use settings such as font, color, and indentation to distinguish heading levels.

Style: As stated in 3.3.3 Style, for some people it is difficult to read text that is all italicized or underlined, and for some bold text is easier to read. In addition to overall changes, some people need to make element-level changes. For example, a person might set all text to bold, and then for text that is marked up to be bold they use different settings such as font or color to distinguish it.

For this to work, content needs to be marked up appropriately based on semantic meaning.

The images below show example web content dispayed with real user style sheets using element-level customization.

shawna-slh added a commit that referenced this issue May 27, 2016
Addressed issues:
* #30
* #28
Proposal for:
* #50
@lauracarlson
Copy link
Contributor

Agree with Shawn's approach.

Suggest replacing "semantic meaning" as it seems redundant. Something such as "semantic structure" may be more accurate.

@shawna-slh
Copy link
Collaborator Author

shawna-slh commented Jun 2, 2016

+1 to Laura "semantic meaning" -> "semantic structure"
Resolution in 2 June 2016 telecon

@shawna-slh
Copy link
Collaborator Author

Done. (will upload updated version soon)

@allanj-uaag
Copy link
Contributor

added statements to ​Australian Blindness Forum (ABF) comment. waiting for other issues to be closed to complete the reply.

@allanj-uaag
Copy link
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants