Skip to content
This repository has been archived by the owner on Jun 30, 2018. It is now read-only.

Visual presentation #51

Closed
lseeman opened this issue Nov 27, 2016 · 32 comments
Closed

Visual presentation #51

lseeman opened this issue Nov 27, 2016 · 32 comments

Comments

@lseeman
Copy link
Contributor

lseeman commented Nov 27, 2016

SC Shortname: Visual Presentation

SC Text

Allow for the ability to easily adjust white space around objects and text, including boxes, paragraph headings, and content, to a degree that suits the user and does not disrupt the overall integrity of a web page.

Current:

1.4.8 Visual Presentation: For the visual presentation of blocks of text, a mechanism is available to achieve the following (Level AAA):

  1. Foreground and background colors can be selected by the user.

  2. Width is no more than 80 characters or glyphs (40 if CJK).

  3. Text is not justified (aligned to both the left and the right margins).

  4. Line spacing (leading) is at least space-and-a-half within paragraphs; and paragraph spacing is at least 1.5 times larger than the line spacing.

  5. Text can be resized, without assistive technology, up to 200 percent in a way that does not require a user to scroll horizontally to read a line of text on a full-screen window.

Proposed:

1.4.8 Visual Presentation: For the visual presentation of blocks of text and objects, a mechanism is available to achieve the following (Level AA):

  1. Foreground and background colors can be selected by the user.

  2. Width is no more than 80 characters or glyphs for Latin and Semitic based languages; or 40 for Chinese, Japanese, and Korean; or can be selected by the user.

  3. Text is not fully justified (aligned to both the left and the right margins), or justification can be set by the user.

  4. Line spacing (leading) is at least space-and-a-half within paragraphs; and paragraph spacing is at least 1.5 times larger than the line spacing.

  5. Text can be resized, without assistive technology, up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text on a full-screen window.

  6. Increased line and border spacing can be added around blocks of text and objects, such that they can be increased up to 200% without loss of content or functionality.

Include https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-visual-presentation.html

Suggestion for Priority Level (AA)

AA

As this can be enabled via personalization, it is widely applicable.

##Related Glossary additions or changes

##What Principle and Guideline the SC falls within.

Guideline 1.4 Distinguishable: Make it easier for users to see and hear content, including separating foreground from background.

Or under the personalization guideline

Description

White space, also described as negative space, reduces clutter and provides definition to content so that the viewer is given a clear overview of a web page. It is used by designers to enhance text and the position of objects on a page.

Benefits

Use of white space aids navigation through a page and improves readability. It can enhance tracking, where there is a considerable amount of text, and guides the user to important elements on a page. For those with cognitive impairments, it has been shown to ease reading difficulties and enable better comprehension of content.

The capability to adjust the amount of white space around objects and text supports the ability to identify important elements in the content of a web page.

Also see our Background research document.

Related Resources

“Accommodating-ASD-In-STEM.pdf”. Nathan W . Moon, PhD Robert L. T odd, M S David L. Morton, PhD Emily Ivey, M S.

See http://www.bdadyslexia.org.uk/about-dyslexia/further-information/dyslexia-style-guide.html
Related Resources (optional)

Resources are for information purposes only. No endorsement is intended or implied.

Testability

Each bulleted item in the success criteria is objective and can be verified.

Techniques

  • Setting a clear and easy-to-read format using CSS.
    * Enabling a clear and easy-to-read format via personalization.
    * F32: Failure of SC 1.3.2 due to using white space characters to control spacing within a word.
    * F33: Failure of SC 1.3.1 and 1.3.2 due to using white space characters to create multiple columns in plain-text content.
    * F34: Failure of SC 1.3.2 and 1.3.2 due to using white space characters to format tables in plain-text content.
  • F88: Failure of Success Criterion 1.4.8 due to using text that is justified (aligned to both the left and the right margins).

More information:

CSS/Properties/white-space
The CSS layout model - boxes, borders, margins, padding.
Internationalization and white space

"Careful control of whitespace is among a designer’s most important tools – and in the opinion of this author, the single most important. However, the degree of control over whitespace that brings high production values to a site design is absent from default browser stylesheets, which means that stylists typically make frequent use of the margin, border, padding, and other CSS layout properties explained in this article." https://www.w3.org/community/webed/wiki/The_CSS_layout_model_-_boxes_borders_margins_padding

WebAIM Text/Typographical Layout – white space

Issue papers

Personalization and Preferences

@joshueoconnor
Copy link
Contributor

@lseeman
Copy link
Contributor Author

lseeman commented Jan 17, 2017

If the other items are dealt with in other SC maybe we should just have this as a SC as a new SC:

"A mechanism is available for increasing line and border spacing around blocks of text, graphics and embedded elements and objects and regions, such that they can be increased up to 200% without loss of content or functionality.

Are the other items fully included in #58 #57 ?
@WayneEDick @lauracarlson

Note we should use the aria definition of regions

@lseeman
Copy link
Contributor Author

lseeman commented Jan 17, 2017

https://www.w3.org/TR/wai-aria/roles#region
Also all landmark roles are examples of the region role

@joshueoconnor
Copy link
Contributor

@eadraffan Can I have a status update on this please?

@eadraffan
Copy link

I need to check with Lisa as it appears that part of this SC could be inlcuded within #58 and #57 but the latter has received many comments. I will try to attend Monday's meeting to clarify this SC and #50

@lseeman
Copy link
Contributor Author

lseeman commented Feb 5, 2017

I added comments on #57 and #58 to check with them. Maybe send Wayne an email aslking him what thew current wording of each one is.,

@alastc
Copy link
Contributor

alastc commented Feb 6, 2017

@lseeman I think there are two overlapping SCs from the LVTF:

The main difference for #78 is that we're trying to avoid the 'mechanism is available' approach, so it starts: "No loss of content or functionality on a webpage is caused by overriding"... font family etc.

The linearisation one still uses the 'mechanism' language, but we might have to re-word that at some stage.

On the list I outlined 4 levels of adaptation to personalisation, and we're trying to keep these in the first 2 levels where the author needs to avoid certain things, but doesn't have to add functionality. Linearisation breaks into level 3, so best kept separate.

The assumptions behind these seem to be different, for the LVTF SCs the user has to apply the adaptations, is that the case here? If so then I think #78 would work for both and the approach is more likely to survive the process.

@eadraffan
Copy link

eadraffan commented Feb 6, 2017

I agree that if we take from #78 "line-height of all text to 1.5, letter-spacing to TBA, and word-spacing to TBA. (TBA= Wayne is researching)" that would help with text and increase white space through personalisation. However, we still have to deal with the ability to alter justification and colour changes not just high contrast mode as in #78? But are these in other SCs? If so then we can go with Lisa's idea "A mechanism is available for increasing line and border spacing around blocks of text, graphics and embedded elements and objects and regions, such that they can be increased up to 200% without loss of content or functionality."

@alastc
Copy link
Contributor

alastc commented Feb 7, 2017

Hi @eadraffan, if the user can do those things (font-family, spacing, line height, colors), then changing the justification or using another colour scheme are easy and doesn't require the author to support them.
I.e. justification doesn't expand elements, it just spaces text within an element differently. If the user sets the colours to black & white, using another colour scheme should also be possible.

The issue is to what degree these are achieved by the author. The assumption on the LVTF side is that the user is adapting the site, and the author isn't preventing them.

I'm not sure what the effect (e.g. the CSS) for increasing "border spacing" would be? Border is one property, spacing another, what's border spacing? Assuming it just means the spacing around the elements, I'm not sure how the user would achieve that? Or does the author need an explicit interface widget?

@lseeman
Copy link
Contributor Author

lseeman commented Feb 7, 2017 via email

@eadraffan
Copy link

Yes I am Lisa and it is my lack of coding skills that means I may use the incorrect terms. Many apologies.

@alastc
Copy link
Contributor

alastc commented Feb 7, 2017

Hi Lisa,

If the user is overriding the styles, I'm not sure how the author could block them overriding the justification? If I added that to the bookmarlet it would be something like:

$("*").css('text-align', 'left');

The author can't block that if it is done by an extension.

The kind of techniques needed for font-family & spacing will be around allowing text to resize without breaking the layout, rather than allowing/preventing the user from applying styles. For a couple of other things we dropped SCs because it wasn't things authors could do/prevent.

Expanding margins around elements by 200% (independently of zoom?) is more difficult, without personalisation I'm not sure how that could be achieved in HTML/CSS.

The nearest equivalents for low vision is covered by Resize content (with browser zoom) and Linearise (override layout to make it 1 column).

Cheers,

-Alastair

@eadraffan
Copy link

Browser zoom is not great for those with cognitive impairments as the whole page with all the contents are enlarged and those with reading difficulties do not necessarily want large images, but do need to have the text redefined to suit their needs. Added white space around blocks of content also makes for easier reading and clear guidance to content on a page. But I quite understand that not all pages need to be designed specifically for those with intellectual disabilities as per the examples below. Can personalisation offer the possibility of being able to add more space around content. We go Ctrl+ for zoom, can we have a short cut for 'add more space around blocks, reflow and linearise if necessary'!

Examples of good use of white space
http://www.easy-read-online.co.uk/easy-access.aspx
https://www.mencap.org.uk/learning-disability-explained

@lseeman
Copy link
Contributor Author

lseeman commented Feb 8, 2017

Hi @alastc . I think you just add padding around your regions and blocks in CSS.
However as you can not do this to all the divs you need the auther to check this works

@lseeman
Copy link
Contributor Author

lseeman commented Feb 8, 2017

"Spacing: Line spacing between paragraphs, blocks of text, graphics and embedded elements and objects and regions is at least 0.8em vertically and 0.5em horizontally and line spacing in cursive script languages have a line high of at least 150% unless a mechanism is available such that they can be increased up to 200% without loss of content or functionality. "

em is defined as
one em unit is equal to the computed font-size for the element to which the em is applied

more explanations
some people with disabilities will be using tools to add diacritics to cursive script languages -
there needs to be space
EA and I looked at samples of different white space combinations to find a balance between readability and asking too much. Note that EA works with people who need this on a daily basis.

I can scree share if you like. i put it on the low side , but i think it is as high as is reasnoble

@alastc
Copy link
Contributor

alastc commented Feb 8, 2017

Hi @lseeman, @eadraffan,

I'm just trying to think through what authors have to do (i.e. what the content-requirement is), and it depends on your assumptions, is the scenario that:

  1. The user is overriding styles with the UA.
  2. The user is overriding styles with the UA according to some pre-agreed signal.
  3. The author is providing a control in the page.
  4. Personalisation where the site provides information that enables more effective adaptation.

The first option is probably the most feasible, although it is being argued about on LVTF SCs as well. The last option is the easiest to define here because you just need to say "provide a layout for when people tick the wide-spacing option", although that is extra work for every website and will get push back. (As would option 3.)

If the assumption is 1 or 2, then it aligns with the assumptions of the LVTF ones and I would suggest either combining them, or at least taking a similar approach on wording. I.e.

No loss of content or functionality on a webpage is caused by overriding the...

If the assumption is 3 or 4 (or 'mechanism available' which means 3 or 4 to start with), then we should go into FPWD with them separate.

Looking at option 1, spacing and layout adjustments are the hardest to apply via UA because if you override certain aspects it will break layouts. For example something like this:

div { padding: 0.8em !important;}

Would destroy any layout with nested divs.

Would it be suitable to ensure that blocks of text are well spaced, rather than everything? E.g.

p, li, h1, h2, h3, h4, h5, h6 {margin: 1em !important;}

Those elements tend not to be used for layout (except perhaps li), so are less likely to break layouts.

Going down that route, the techniques could be things like:

  • Use proper HTML elements for blocks of text (p, li, Hx etc).
  • Don't set fixed heights on containers of text (already there I think?)

For option 2, we could add a technique around allowing pre-defined regions (in the ARIA sense) to have extra padding. E.g. banner, main, complementary, contentinfo. Not nav or search as they are often nested within other regions.

That could be something like: Only apply this spacing with the main element (if that meets the user-need), so something equivalent to:

main p, main li, main h1, main h2, etc {margin: 1em !important;}

Just trying to think it through to the content-requirements (i.e. what the designer/developer/site owner has to do).

@eadraffan
Copy link

eadraffan commented Feb 8, 2017

Lisa I really like your new wording "Spacing: Line spacing between paragraphs, blocks of text, graphics and embedded elements and objects and regions is at least 0.8em vertically and 0.5em horizontally and line spacing in cursive script languages have a line high of at least 150% unless a mechanism is available such that they can be increased up to 200% without loss of content or functionality. "

Please does anyone have a problem with this? It will be submitted for a pull request if we do not have an comments by the end of the day.
@alastc @WayneEDick @lauracarlson

@liamquin
Copy link

liamquin commented Feb 8, 2017 via email

@eadraffan
Copy link

This discussion was leading on from the explanations given by Alastair Campbell @alastc and the fact that some spacing around blocks of text does not work for all languages. If you are using a large screen or mobile device you still do not want cramped blocks of content. I am not sure how one personalises this but Lisa showed me examples of how it could be achieved.

@alastc
Copy link
Contributor

alastc commented Feb 8, 2017

So the same distance apart on a projected wall and on a mobile 'phone?

Proportionally. EMs are calculated to CSS pixels, which are relative between devices.

Please does anyone have a problem with this?

I'm not clear what the assumption is regarding it being a UA override, or something the site has to provide?

@lseeman
Copy link
Contributor Author

lseeman commented Feb 8, 2017

@liamquin - No it is proportional. see the definition given of EM (which will have to be included)

@lseeman
Copy link
Contributor Author

lseeman commented Feb 8, 2017

@alastc we are giving a choice.
you can do it without any personalization by just having sufficient white space. you can enable personalization either by good mark up or by any other means you want.
We will provide a technique and test file for the personalization though good mark up options.
The semtics required are simply good HTML and landmark roles

@alastc
Copy link
Contributor

alastc commented Feb 9, 2017

But the last item in the SC text says you need to be able to "increase" the spacing by 200%, that is more than having 'sufficient white space' (which isn't defined, and probably can't be!). That would penalise a site which does have lots of padding because then you need to allow for doubling it?

@liamquin
Copy link

liamquin commented Feb 9, 2017 via email

@eadraffan
Copy link

I think that is the problem we just want to make it possible to have a reasonable amount of space around blocks that can be adapted to suit the user. This may not be possible, but Lisa seemed to be able to achieve it, although I understand you are saying it has to be flexible.

@alastc
Copy link
Contributor

alastc commented Feb 9, 2017

Lisa seemed to be able to achieve it

Where you control both the UA side and the website, that is fairly straightforward.

The wider application of that approach would require every website to provide a personalisation mechanism that matches what the UA expects.

Regarding the feasibility of the proposed adaptations for websites designers developers:

  • Colors are relatively straightforward apart from odd image backgrounds (and overlaps with Adapting text #78)
  • Width of 80 chars is rather prescriptive, it would be ok for article type pages, but much harder for dashboards and overview pages.
  • Justification is easily done on the UA side, we didn't try to cover that in Adapting text #78.
  • Line spacing of 1.5 within paragraphs will generally be easy (overlaps with Adapting text #78).
  • Text can be resized 200% without horizontal scrolling is less than the requirement from Zoom Content (formerly Resize content) #77.
  • Increasing "border spacing" proportionally 200% will break layouts unless they are specifically designed to do that. The closest thing from LVTF is Issue 58 linearization (was reflow) #89 Linearisation, where the user completely overrides the layout to one column (not really what you want here?)

As I said above, it really depends whether you expect users to have a UA (e.g. extension) to apply some of these. If so, I'd remove the ones that overlap with #78 & #77.

@lseeman wrote:

we are giving a choice. you can do it without any personalization by just having sufficient white space.

In which case you need to define what 'sufficient white space' is, otherwise every website would have to allow for the user to double the padding around text (as written in the SC), which would be harder for those that do provide sufficient space.

The semtics required are simply good HTML and landmark roles

In which case you don't need this SC, just add some techniques to 1.3.1.

NB: That is the pushback we had on the LVTF adaptation SCs, and I would anticipate you get the same sort of response. That is why we focused on what the content requirements are in #78.

@lseeman
Copy link
Contributor Author

lseeman commented Feb 9, 2017

You can do it by hard coding or by personlization but you need to test that it works via personlization or you have not done it. add some techniques to 1.3.1. will not achieve this
There needs to be a test profile (wich i am hoping to write with LVTF) that people can test against that text is not cut out or overridden. 1.3.1. helps you get there but does not mean that the page is now readable. and it is not just about readability but can I absorbe and focus on that part of the page

we completely defined what sufficient white space is in the new version. hope that is Ok now (you might have been looking at the origial which is long been discarded)

@eadraffan
Copy link

Thank you Lisa - I have returned to the last set of words for this SC namely: "Spacing: Line spacing between paragraphs, blocks of text, graphics and embedded elements and objects and regions is at least 0.8em vertically and 0.5em horizontally and line spacing in cursive script languages have a line high of at least 150% unless a mechanism is available, such that they can be increased up to 200% without loss of content or functionality."

Lisa has explained the situation and I have read the comments so far. Please could there be a bit more consensus around this one as it is going as it stands if we hear nothing more. Sorry for pushing this.

lseeman added a commit to lseeman/wcag21 that referenced this issue Feb 9, 2017
@lseeman
Copy link
Contributor Author

lseeman commented Feb 9, 2017

Pull request made - Spacing - issue 51 #113

@lseeman lseeman closed this as completed Feb 9, 2017
@alastc
Copy link
Contributor

alastc commented Feb 9, 2017

you might have been looking at the origial which is long been discarded

It would help to keep the text at the top up to date. You mentioned the frustration of people not reading it through properly, so I did, but then missed a very different version further down...

Anyway, time to move onto the pull request version.

@lseeman
Copy link
Contributor Author

lseeman commented Feb 10, 2017 via email

@jspellman
Copy link

Issue 51 is much harder, IMO, because:

  1. It should be handled by the browsers, not content authors. It's unfair to make authors do it.

  2. the limitations of HTML and CSS (which Alastair and Liam discussed)

Here's my proposal:

Object Spacing: Negative space (also called "white space") meets all of the following conditions:
a) Line spacing between paragraphs, headings, and blocks of text is at least 0.8em vertically and 0.5em horizontally
b) Spacing between graphics, embedded elements, objects and regions is at least 0.8em vertically and 0.5em horizontally where em is at least the size of the smallest text displayed.
c) Line spacing in cursive script languages have a line high of at least 150% (200% is preferred).

More on 1) (if you want more ideas, of what life could be like if the major browsers hadn't killed off UAAG 2.0)

UAAG 2.0 deals with this in Guideline 1.4 Provide Text Configuration. https://www.w3.org/TR/UAAG20/#gl-text-config

The first 3 success criteria are most relevant to this proposal.

1.4.1 Basic text formatting (Globally): The user can globally set all of the following characteristics of visually rendered text content: (Level A)

  • Text scale with preserved size distinctions (e.g. keeping headings proportional to main font)
  • Text color and background color, choosing from all platform color options
  • Font family, choosing from all installed fonts
  • Line spacing, choosing from a range with at least three values up to at least 2 times the default
  • Text style, choosing to turn on/off underline, italic, bold

1.4.2 Basic text formatting (by Element): The user can set all of the following characteristics of visually rendered text content for text element types including at least headings, input fields, and links: (Level AA)

  • Text size (e.g. 18 point) or scale (e.g. 150%)
  • Text color and background color, choosing from all platform color options
  • Font family, choosing from at least all installed fonts
  • Line spacing, choosing from a range with at least three values up to at least 2 times the default
  • Text style, choosing to turn on/off underline, italic, bold
  • Margins around blocks of text
  • Borders

1.4.3 Blocks of text (Globally): The user can globally set all of the following characteristics of visually rendered blocks of text: (Level AA)

  • Character spacing, choosing from a range with at least 5 values
  • Justification (left or right, including turning off full justification)
  • Margins around blocks of text
  • Borders

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

No branches or pull requests

6 participants