-
Notifications
You must be signed in to change notification settings - Fork 18
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
Comments
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 |
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.
|
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. |
Currently:
Suggest: Add definition of "blocks of text" (from WCAG). Add note something like "(This applies to blocks of text, not individual words or phrases.)":
Currently:
Suggest: Expand this to clearly cover things like links, em, strong, etc. Thoughts on how we want to expand this? Ideas for wording? |
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.
|
merged Shawn and Laura
Perhaps change the last sentence to be
|
new wording |
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:
|
For 3.5.1 Element-level Customization, there are several issues here and I think we want to address them in separate paragraphs. Proposal:
|
Agree with Shawn's approach. Suggest replacing "semantic meaning" as it seems redundant. Something such as "semantic structure" may be more accurate. |
+1 to Laura "semantic meaning" -> "semantic structure" |
Done. (will upload updated version soon) |
added statements to Australian Blindness Forum (ABF) comment. waiting for other issues to be closed to complete the reply. |
From 6 April telecon (after item 7) (spurred by Issue #41)
We need to rethink this issue overall, including what we say in
The text was updated successfully, but these errors were encountered: