search

w3c / wcag

Web Content Accessibility Guidelines
https://w3c.github.io/wcag/guidelines/22/
Other
1.11k stars 252 forks source link

Potential failure techniques (or at least checks) for Text Spacing? #683

Open mbgower opened 5 years ago

mbgower commented 5 years ago

From C36

In English languages, if authors do not set the CSS height property, it can help ensure paragraphs expand. Paragraphs need to allow text to increase vertically for languages or scripts such as English which are read horizontally or to increase horizontally for languages or scripts which are read vertically.

From C35

There is some variability in the width that words or phrases will grow to when setting the letter and word spacing. If elements must use a fixed width, a safe value is 20% wider than the default maximum width. For example, if a small text-container allows for 20 characters, allowing enough width for 24 characters should allow enough space for text-spacing to be applied.

For boxes which can expand with the text, authors can take advantage of the inline-block value of the CSS display property and not set negative margins to allow for text-spacing overrides.

@nitedog , reviewing these two techniques could these statements and others potentially be incorporated into some Auto-wcag rules? Not sure if you are creating PVs or not...

nitedog commented 5 years ago

Thanks @mbgower, I forwarded your comment to the Auto-WCAG GitHub (which will soon move to become ACT Rules CG!).

WayneEDick commented 5 years ago

I have tested many websites with the full inline spacing and have encountered no failures. The failures I did encounter were vertical. The line spacing causes the captions (I don't know if actual figcaption elements are used) to overflow in galleries. Movement to grid structures would be one way to fix this problem. Using tables without the flexibility to grow down truncates captions. This seems related to C4

On Thu, Apr 4, 2019 at 10:35 AM Shadi Abou-Zahra notifications@github.com wrote:

Thanks @mbgower https://github.com/mbgower, I forwarded your comment https://github.com/auto-wcag/auto-wcag/issues/469 to the Auto-WCAG GitHub https://github.com/auto-wcag/auto-wcag (which will soon move to become ACT Rules CG!).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag/issues/683#issuecomment-479992927, or mute the thread https://github.com/notifications/unsubscribe-auth/AH0OF_bZrSqU99MFyx2Pvv5ud62czcLvks5vdjfwgaJpZM4cbNlF .

alastc commented 5 years ago

Is there any action for AGWG here?

nitedog commented 4 years ago

This can be closed from ACT TF perspective.

mbgower commented 4 years ago

@nitedog if it can be closed, could you please indicate what action was taken, or what you rationale was for dismissing C36, C35 (and per Wayne's comment, potentially C4) as potential checks in Auto-WCAG?

nitedog commented 4 years ago

@WilcoFiers can confirm. As far as I understand, this suggestion was brought to the ACT-R CG (formerly Auto-WCAG) but after one year there was still no one available to write rules and promote implementations for this. The suggestion itself was not dismissed, and anyone is welcome to attempt such rules.

mraccess77 commented 4 years ago

There is an ACT rule for text spacing but it only checks with inline styles are used with important to control text spacing -- so it's very limited and not very likely to occur in my opinion. I believe a pass rule exists for when text spacing is set to the specified levels by default - which indicates success - but again is likely to not occur.

nitedog commented 4 years ago

@mraccess77 ACT rules development relies on people willing to take on the work. Nobody had stepped up to write rules according to these proposals. Would be delighted if you or someone else in your organization may be available and interested?