10000 Adapting text · Issue #78 · w3c/wcag21 · GitHub
[go: up one dir, main page]
Skip to content
This repository was archived by the owner on Jun 30, 2018. It is now read-only.

Adapting text #78

Closed
allanj-uaag opened this issue Dec 1, 2016 · 444 comments
Closed

Adapting text #78

allanj-uaag opened this issue Dec 1, 2016 · 444 comments
Assignees
@lauracarlson
Labels
~comment-text-spacing Integrated into Draft Guidelines LVTF

Comments

@allanj-uaag
Copy link
Contributor
allanj-uaag commented Dec 1, 2016 •
edited by lauracarlson
Loading

Current versions of SC and Definitions

Open Issues and Survey Results

(Links to surveys require W3C Member access)

SC Shortname

Adapting text

Note: This SC merges 79 Font Family, 78 Spacing, and 74 Text Color as they are very similar in aim (ability to override and adapt text).

SC Text

If the technologies being used allow the user agent to adapt style properties of text, then no loss of essential content or functionality occurs by adapting all of the following:

  1. line height (line spacing) to at least 1.5 times the font size
  2. spacing underneath paragraphs to at least 2 times the font size
  3. letter spacing (tracking) to at least 0.12 times the font size
  4. word spacing to at least 0.16 times the font size

Note: Examples of text that are typically not affected by style properties are open captions and images of text, which are not expected to adapt.

Editor's note: The Working Group seeks to include overriding text color, background color, and font-family as part of this SC, but is not yet able to identify a way to do so that is sufficiently testable.

Suggested Priority Level

Level AA

Related Glossary additions or changes

adapted
Formatting being overridden by the client.
Style Properties
Properties whose values determine the presentation (e.g. font, color, size, location, padding, volume, synthesized speech prosody) of content elements as they are rendered (e.g. onscreen, via loudspeaker, via braille display) by user agents. Style properties can have several origins:
  • user agent default styles: The default style property values applied in the absence of any author or user styles. Some web content technologies specify a default rendering; others do not.
  • author styles: Style property values that are set by the author as part of the content (e.g. in-line styles, author style sheets).
  • user styles: Style property values that are set by the user (e.g. via user agent interface settings, user style sheets).

What Principle and Guideline the SC falls within.

Principle 1, Guideline 1.4

Description

The intent of this Success Criterion is to help ensure that people with low vision can override font family, text colors, and spacing. People with low vision often must override author settings via user stylesheet, bookmarklet, extension or application such as VIP-PDF Reader.

This SC sets metrics for a normative testable values. Any particular user is likely to choose different values (especially font & color).

The principle is that if you override the font (with any font), the issues appear. E.g. font-icons disappear. Same for colors, the act of changing them at all will highlight most or all issues people would get from changing them to their preferred colors.

Line-height, letter-spacing, and word-spacing metrics were chosen as measures based on Research. McLeish ran from .04 to .25 em tests (Wayne E. Dick PhD analyzed the McLeish study and translated from points). McLeish found an increasing curve in reading speed of actual materials up to .25, but it really started to flatten at .20. Previous studies that reported no improvement started at .5em. Right at the flat point. Hence Wayne recommends letter spacing be 0.12em, and word spacing be 0.16em for this SC.

The plan is to start testing sites with these metrics on the various user-agent tools, primarily bookmarklets created specifically for this. See where problems surface. Adjust measures if needed. And then provide techniques.

Benefits

Font Family

Some fonts/typefaces are more readable than others. For example, some people cannot read fonts with sub-pixel rendering...

User Need: Users can change the font face (also called font family or typeface) of all text, choosing from a wide range of fonts including sans serif and serif fonts..

Source: Accessibility Requirements for People with Low Vision, Section 3.3.2

Text Color

...some people need low brightness, especially for backgrounds. Some people, who need low brightness for backgrounds, also need low brightness overall, and thus need low-brightness text.

Other people need high contrast between text and background, including many older people who lose contrast sensitivity from ageing. Some read better with dark text on a light background.

For some people, common color combinations or colors from a limited color palette work fine. For example, black text on a white background, or the inverse, with white text on a black background. Other people need to select more-specific background and text colors. For example, people, who require low brightness overall, need to select the specific background and text colors that provide sufficient contrast for them, yet not too-high brightness. Readable and optimal color combinations differ vastly among individuals, and can even vary from one individual to another, depending upon conditions such as fatigue and lighting.

Figure 8: Web page with author-defined colors with low contrast - light background, gray text, light green headings:

screen capture

Figure 9: Web page with user style with medium contrast - brown background, tan text, headings of different dull colors:

screen capture

Figure 10: Web page with user style with high contrast - black background, white text, headings of different bright colors

screen capture

User Need - Contrast: Users can set the background color and the text color from the full color spectrum.

Source: Accessibility Requirements for People with Low Vision, Section 3.1.2 Text Contrast

Spacing

Spacing such as space between lines and space between words impacts readability.

The space between lines in a block of text is also called leading. Some people need more space between lines to be able to read text. Line spacing also helps with tracking.

User Need: Line Spacing: Users can change the line spacing (leading) for blocks of text.

Source: Accessibility Requirements for People with Low Vision, Section 3.4.1

Some people need more space between letters to read text.

User Need: Letter Spacing: Users can change the letter spacing (space between letters/characters) of blocks of text.

Source: Accessibility Requirements for People with Low Vision, Section 3.4.2

Some people need more space between words to read text.

User Need: Word Spacing: Users can change the word spacing (space between words) of blocks of text.

Source: Accessibility Requirements for People with Low Vision, Section 3.4.3

Testability

Using a bookmarklet, user stylesheet, or VIP-PDF Reader change:

  1. line height (line spacing) to at least 1.5 times the font size
  2. spacing underneath paragraphs to at least 2 times the font size
  3. letter spacing (tracking) to at least 0.12 times the font size
  4. word spacing to at least 0.16 times the font size
  5. font family to a different font family (e.g. Verdana if that is not in use)
  6. foreground color and background color to a different foreground color and background color (e.g. white on black if that combination is not in use)

Expected Results

  • No loss of content or functionality.

Techniques

Existing Related Techniques

New Techniques

  • Allowing for override of spacing (draft technique)
  • Allowing for override of font family (new technique)
  • Allowing for override of text color (future technique)

Related Information

Articles

Public and Member Comments

Research

Tests

Tools

Email

Minutes

GitHub

Wiki Pages
@lauracarlson
Copy link
Contributor

Signing up as SC Manager for Issue 78.

@lauracarlson
Copy link
Contributor

@DavidMacDonald noted on his spreadsheet that this proposal does not seem to meet the "All Technologies" SC acceptance criteria and that it is "Not Mature User/Agent issue".

Thoughts?

@patrickhlauke
Copy link
Member

Not all browsers - particularly on mobile/tablet devices - support user stylesheets, and don't provide any browser/OS level controls that are this granular. The only possible solution for an author to meet this SC would then be to implement a complete customisation/personalisation system for their page/site, which is technically non-trivial and onerous (for a AA, and even a AAA). In my opinion, of course.

@alastc
Copy link
Contributor
alastc 8000 commented Dec 19, 2016

I think there are a couple from LVTF are are essentially 'passed' when you use HTML based tech, but the idea was to include it to add the requirement other technologies. I believe this is one?

For anyone coming to it fresh it appears to ask for customisation, but that isn't the aim.

It would be useful for Jim or someone more familiar with that to raise it at WCAG level, as I think it is "mature" and tech-neutral, but aimed at non-HTML technologies.

@DavidMacDonald
Copy link
Contributor
DavidMacDonald commented Dec 19, 2016 •
edited
Loading

My concern is that this really is a User agent issue. I dread the thought of telling large companies to use up prime real estate (i.e. top right) with a gears icon and a bunch of CSS swapping radio buttons in there. Currently, EDGE reading mode is doing this kind of thing. So I agree with Patrick on this. I think this is too much for a dot release, given our other new LVTF requirements which are more mature and achievable.

@alastc
Copy link
Contributor
alastc commented Dec 19, 2016

But no-one is saying that a website would have to provide customisation options.

If you use HTML you pass, if you use something else, you may need to provide options.

@lauracarlson
Copy link
Contributor

@allanj-uaag , @slhenry , and @WayneEDick your thoughts on whether this SC is a user agent issue and be should deferred to Silver? Please see David's and Patrick's comments.

The proposed text does say that "a mechanism is available...", which gives the impression of add-on widgets. Ideas to reword it?

@alastc
Copy link
Contributor
alastc commented Dec 21, 2016 •
edited
Loading

So it seems people are having a similar reaction to me when when I joined the LVTF, thinking that it is requiring on-page widgets when in fact HTML passes by default.

There needs to be a way of saying that in the SC text, but somehow not make it technology specific!?

The closest thing in WCAG 2.0 is from 1.4.5 Images of text, which starts: “If the technologies being used can achieve…”

Perhaps something like “If the technologies being used do not provide element level access, a mechanism is available to achieve the following:"

Where "element level access" is a term for markup languages. Any other ideas?

@lauracarlson
Copy link
Contributor

Hi @DavidMacDonald and @patrickhlauke,

Would Alastair's suggested SC text work for you?

Thanks,
Laura

@patrickhlauke
Copy link
Member
patrickhlauke commented Dec 21, 2016 •
edited
Loading

In practice, even with that particular text, it would mean requiring even HTML/CSS based sites that are to be displayed on the currently common mobile platforms/browsers to provide actual widgets/personalization options (since to my knowledge none of the browsers on iOS/Android/Windows Mobile provide this sort of element-level granular control, nor any form of user stylesheet options). So this seems very ambitious and onerous as a AA, even with that text.

@lauracarlson
Copy link
Contributor

Thank you @patrickhlauke . I really appreciate your expertise on the mobile front. Can you think of any other possible way to word the SC that could work?

@patrickhlauke
Copy link
Member
patrickhlauke commented Dec 21, 2016 •
edited
Loading

I don't believe the problem is one of wording as such. It's just that no UA (on mobile/tablet) currently offers the necessary mechanism to satisfy the suggested requirement of the SC, meaning that in these scenarios authors effectively HAVE to provide a widget or some form of per-site personalization. Not sure how this tension could be resolved...if what the SC is proposing is indeed needed by particular user groups, one could argue that those user groups would not be using devices/UAs that don't provide this customisation option, but that's potentially a self-fulfilling prophecy/circular argument, unless I'm missing something obvious...

@lauracarlson
Copy link
Contributor

Thanks, @patrickhlauke .

@allanj-uaag , could you please add this to the next LVTF agenda?

@goetsu
Copy link
goetsu commented Dec 26, 2016

Is it an invitation for authors to implement feature to let user choose spacing he want ? in that case better to be AAA I think because can be costly to implement

@bruce-usab
Copy link
bruce-usab commented Jan 3, 2017 •
edited
Loading

Just now signing up for GitHub...

I am okay with this SC, but think it needs to be at same level as 1.4.8 (currently AAA) because (as compared to 1.4.8):

  • It does less for people low vision (I think)
  • It impacts the visual design more
  • It is more work for content authors

I would also recommend a note similar to 4.1.2:

This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.

@lauracarlson
Copy link
Contributor
lauracarlson commented Jan 5, 2017 •
edited
Loading

On the January 5, 2016 LVTF call we discussed having an exception for UAs that do not provide a way to adjust spacing. If the user-agent does not have a way (such as mobile does not currently allow user style sheets), authors would be exempt. This SC would not be applicable in those cases.

However, authors would be responsible for where it is indeed feasible such as HTML on desktops. Lots of low vision folks can't do things on mobile but having this SC at AA where it is accessibility supported via user stylesheets would be a big benefit.

@slhenry also mentioned that having a failure technique for authors using element-level CSS marked important for spacing would be helpful for people with low vision because per @WayneEDick users can't overwrite that to what they need. Both Wayne and Shawn are user style sheet users.

First attempt at rewording the SC:

For the visual presentation of blocks of text:

  • character spacing can be selected by the user
  • word spacing can be selected by the user
  • line spacing can be selected by the user
  • paragraph spacing can be selected by the user

with following the exception:

  • If the user agent prohibits adjustments the content is exempt.

@DavidMacDonald , @patrickhlauke, @bruce-usab , @alastc thoughts?

@lauracarlson
Copy link
Contributor
lauracarlson commented Jan 5, 2017 •
edited
Loading

@goetsu No this SC is not about spacing widgets. It is more about letting People with Low Vision who use desktop browsers apply their own stylesheets without authors introducing barriers.

@mbgower
Copy link
Contributor
mbgower commented Jan 6, 2017

The SC does not just call for the ability for users to control spacing, but specifies that a "mechanism" is available to provide that spacing. From that perspective I feel that it does imply that authors are required to customize a mechanism.
There are 8 existing SC that refer to providing "mechanisms", six of which are AAA:
audio control (A)
visual presentation (AAA)
bypass blocks (A)
link purpose (AAA)
unusual words (AAA)
abbreviations (AAA)
pronunciation (AAA)
change on request (AAA)

These break down into 3 broad categories:

  1. situations where IF the author create certain potentially inaccessible content, they provide a means of overcoming it (automatically starting audio; using words in an unusual way; using abbreviations; repeating blocks of content on multiple pages )
  2. situations where IF authors don't follow best practices, they provide a means of overcoming the potential issue (link purpose not clear from link text alone; change of context 8000 are initiated without user request; meaning of word is ambiguous without knowing pronunciation)
  3. the mechanism offers manipulation of information, regardless of author decisions on content (Visual presentation)

This candidate SC aligns very closely with the third case. In fact the 4th requirement for Visual presentation is a near-cousin ("Techniques to ensure 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").

Given that Visual Presentation is AAA, it is tough to rationalize giving this candidate SC a AA designation. As well, it's tough to say this should be a lower level than AAA, because unlike other A and AA that call for mechanisms due to author decisions, this one requires a mechanism regardless of what is being authored.

If the SC wording was altered so that the requirement was not to provide a mechanism, I wonder if this might be easier to consider as a AA. For instance:
"For all text presented in the content, each of the following is true:
word spacing can be adjusted by the user
line spacing can be adjusted by the user
paragraph spacing can be adjusted by the user "

There may be general techniques that could be written to ensure authors do not interfere with user agents (such as G204) or perhaps some CSS techniques which encourage rather than limit malleable spacing. Other have pointed out the technical limitations for some user agents; if someone wanted to support accessibility on such a user agent, they would need to provide a mechanism.

@goetsu
Copy link
goetsu commented Jan 6, 2017

@lauracarlson I understand it better now thanks for your comment.

I agree we must have an exception if the UA doesn't have a feature to let user change spacing adjustments but are you aware of any UA that allow to change it ?

From what I know it not the case for at least Firefox, Safari and Internet Explorer so basically this SC will be always non applicable for now.

Maybe we can consider that Internet Explorer has this feature because it let user specify a user style sheet without any plugin or extension. But, in that case the failure you mention doesn't work because user stylesheet value marked as !important have more weight than author value marked as !important. So the issue isn't about using !important or not it's more about the face that when user use is own stylesheet content must not become unreable if his stylesheet increase spacing

@patrickhlauke
Copy link
Member

Indeed, if user styles are the intended "mechanism" that comes out of the box (rather than requiring an explicit widget etc), it seems that user stylesheets are currently are not supported by Edge at all, and supported in Firefox and Chrome only through the use of third-party plugins. Internet Explorer and Safari still provide options in their settings for them (in IE: Internet Options > General > Accessibility; in Safari: Safari menu > Preferences > Advanced).

And yes, @goetsu is right that !important in a user style should take precedence over author styles, even when those have !important too.

So the issue isn't about using !important or not it's more about the face that when user use is own stylesheet content must not become unreable if his stylesheet increase spacing

The one danger I can see here is that user styles are an unknown quantity for both authors and auditors. It will be difficult to explicitly author against and test all possible values/ways in which user styles try to affect a page. At the very least, a sample "ideal" user stylesheet should be provided for consistent testing, but that still won't guarantee that real-world user stylesheets will do exactly the same, and may still result in situations where a site does not display correctly anymore due to some unforeseen user CSS.

@lauracarlson
Copy link
Contributor

Thanks @mbgower !

Mike, I like your proposed SC text better than my first attempt at it. Much simpler. And the word "adjusted" makes more sense than the word "selected".

Do you think we still need the exceptions? I had the following the exceptions:

  • If spacing of content is essential to that contents use, that part of the content is exempt.
  • If the user agent prohibits spacing adjustments the content is exempt.

A general technique to ensure authors do not interfere with user agents (such as G204) and CSS techniques which encourage rather than limit malleable spacing are great ideas.

@lauracarlson
Copy link
Contributor
lauracarlson commented Jan 6, 2017 •
edited
Loading

Hi @goetsu ,

You are welcome. Thank you for your comment, Aurélien. You asked:

I agree we must have an exception if the UA doesn't have a feature to let user change spacing adjustments but are you aware of any UA that allow to change it ?

VIP PDF Reader was mentioned in the January 5, 2017 LVTF meeting.

But I haven't been able to get it to work. Can anyone?

@lauracarlson
Copy link
Contributor
lauracarlson commented Jan 6, 2017 •
edited
Loading

Hi @patrickhlauke ,

Thank you very much for your comment, Patrick. You wrote:

The one danger I can see here is that user styles are an unknown quantity for both authors and auditors. It will be difficult to explicitly author against and test all possible values/ways in which user styles try to affect a page. At the very least, a sample "ideal" user stylesheet should be provided for consistent testing, but that still won't guarantee that real-world user stylesheets will do exactly the same, and may still result in situations where a site does not display correctly anymore due to some unforeseen user CSS.

Both @slhenry and @WayneEDick are user style sheet users. Shawn and Wayne would it be possible for you two to collaborate to create such a sample "ideal" user stylesheet?

In the the January 5, 2017 LVTF meeting it was mentioned that !important can't be overwritten by users. Shawn and Wayne, do either of you have an example of where this has occurred for you?

@WayneEDick
Copy link
Contributor

In fact a mechanism does exist for at least two user agents to enable user style sheets. So mechanisms exist that are available to users with low vision to apply user style sheets. So, If one uses a laptop or a desktop one can change line, letter and word spacing.
If no mechanism exists for a technology then authors are off the hook. But I don't see why authors of HTML should not code in a way to prevent user style. One that I have run into for example is the use of !important is "style" parameters.

Wayne.

Wayne

@patrickhlauke
Copy link
Member

Random thought: then why not generalise the SC so that all sorts of presentational attributes (beyond just spacing) can be changed using user styles or similar? And the failure examples could then include things like !important and style attributes?

@jnurthen
Copy link
Member
jnurthen commented Jan 8, 2017 via email

@patrickhlauke
Copy link
Member
patrickhlauke commented Jan 8, 2017 •
edited
Loading

Why would !important and inline style attributes fail? An element defined
with !important in the user style sheet will override both of these in the
source document as far as I'm aware.

Just tested this, and yes you're right: providing that a user stylesheet is written appropriately, !important in the author's styles and style attributes do NOT override the user styles. As such, I'd be interested in seeing some hard examples of where authors are breaking user styles... (and where it's not simply the user styles that need to be written more specifically with their selectors - e.g. not just setting style rules purely on body or html, but perhaps using catch-all star selectors * { ... } )

@johnfoliot
Copy link
johnfoliot commented Jul 14, 2017 via email

@lauracarlson
Copy link
Contributor
lauracarlson commented Jul 21, 2017 •
edited
Loading

Hi David, John, Andrew, and all,

@DavidMacDonald

I can live with it.

@johnfoliot wrote:

I can live with this, with the provision that there will need to be some additional explanation in the Understanding documents that clearly explains the measurement criteria in detail.

Thank you, both very much. And John I agree it will need to be explained.

@awkawk Thank you, for integrating the text into the draft guidelines.

Laura

@lauracarlson
Copy link
Contributor
lauracarlson commented Jul 21, 2017 •
edited
Loading

Hi @alastc and all,

Now that the Adapting Text SC has passed the CFC and has been integrated into draft guidelines, Alastair, could you please update your bookmarklet with the metrics specified in the SC text so we can begin testing real world sites?

Previously I created a Wiki page for tracking results. I am wondering if it would it be better for tracking, if we have a table instead of lists. Any preferences?

I can create a new sister page to test and track VIP-PDF Reader results too.

Thank you!

Laura

@alastc
Copy link
Contributor
alastc commented Jul 22, 2017

Hi Laura,

I've updated the script behind the bookmarklet, the best URL for the script is here:
https://alastairc.ac/tests/adaptation-scripts/scripts/text-adaptation.js

I was going to use github raw, but it doesn't use the right mimetype for JS and doesn't seem to work.

I would have thought a spreadsheet would be the best format for taking in results, e.g. a google spreadsheet, so long as the people testing are ok with that (I would be). It could be downloaded as an excel file and then rows could be copied in as a fall-back.

@lauracarlson
Copy link
Contributor

Hi Alastair and all,

@alastc wrote:

I've updated the script behind the bookmarklet, the best URL for the script is here:
https://alastairc.ac/tests/adaptation-scripts/scripts/text-adaptation.js

Thank you!

I would have thought a spreadsheet would be the best format for taking in results, e.g. a google spreadsheet, so long as the people testing are ok with that (I would be). It could be downloaded as an excel file and then rows could be copied in as a fall-back.

I can certainly create a google spreadsheet to track testing results. Is anyone not okay with that approach? Or would you prefer the Wiki? I can always copy the results from google sheets over to the Wiki later.

Thanks again,
Laura

@lauracarlson
Copy link
Contributor

Hello Everyone,

To ascertain how Google sheets may work for testing, I created a draft Adapting Text Testing Results Spreadsheet. Anyone with the link can view it.

Will this work?

Alastair, I gave you editing permissions. Does anyone else want to help test? If so, please let me know and I will give you permissions and you can give it a go.

Thank you,
Laura

@goodwitch
Copy link
Contributor
goodwitch commented Jul 24, 2017 via email

@lauracarlson
Copy link
Contributor
lauracarlson commented Jul 24, 2017 •
edited
Loading

Hi Glenda,

@goodwitch wrote:

I'm interested! Pick me! g

Thank you for volunteering! I have added you as an editor of the Adapting Text Testing Results Spreadsheet.

So far we have 2 tabs at the bottom of the spreadsheet.

The first tab is for testing HTML pages with Alastair's bookmarklet. To use it create a bookmark of any page, and replace the URL with this:
javascript:(function()%7Bdocument.body.appendChild(document.createElement(%27script%27)).src%3D%27https://alastairc.ac/tests/layouts/text-adaptation.js%27%3B%7D)()%3B

The second tab on the bottom of the spreadsheet is to collect data using VIP-PDF Reader.

The SC metrics to set in VIP-PDF Reader are:

  1. line height (line spacing) to 1.5 times the font size
  2. letter spacing (tracking) to 0.12 times the font size
  3. word spacing to 0.16 times the font size

Note: VIP-PDF Reader has no adjustment for spacing underneath paragraphs, so it seems we can't test that. Per the current SC text agreed to by the Working Group, spacing underneath paragraphs is supposed to be at least 2 times the font size.

Thanks again,
Laura

@lauracarlson
Copy link
Contributor
lauracarlson commented Jul 25, 2017 •
edited
Loading

Hello Alastair, Glenda, and all,

I drafted some instructions in the Wiki for how to run Spacing tests for this SC:

Ideas for improvement? These probably can be worked into the Allowing for Spacing Override technique.

If anyone else would like to help test, please let me know and I'll add you as an editor of the Adapting Text Testing Results Spreadsheet. Thank again to @goodwitch , @alastc , and Alastair's colleague Amani.

Thanks,
Laura

@KerstinProbiesch
Copy link

Hi Laura,

depending on the PDF the VIP-Reader is opening a file with a warning, without a warning and it can also happen that it is not possible to open a file with VIP-Reader. For the interpretation of the results it is for sure helpful adding a column in the spreadsheet for these things. Especially when more PDF test cases will be added.

Does any of the PDF files in the list of test cases has one or more a file attachments? I can't say it for sure, but I think that VIP-Reader gives no information when file attachments are present.

@goodwitch
Copy link
Contributor
goodwitch commented Jul 25, 2017 via email

@mraccess77
Copy link
mraccess77 commented Jul 25, 2017 via email

@alastc
Copy link
Contributor
alastc commented Jul 25, 2017

I think in the email discussion we said to start with 1280px wide as per the zoom technique.

I suggest starting with 100% then:

  • test
  • reload
  • Zoom to 200%
  • test
  • reload
  • Zoom to 400%
  • test

I'm not certain it will make any difference, but it would be useful to know if doesn't make any difference!

@lauracarlson
Copy link
Contributor

Hi @KerstinP ,

Kerstin wrote:

depending on the PDF the VIP-Reader is opening a file with a warning, without a warning and it can also happen that it is not possible to open a file with VIP-Reader. For the interpretation of the results it is for sure helpful adding a column in the spreadsheet for these things. Especially when more PDF test cases will be added.

Good point. I added a column to the Adapting Text Testing Results Spreadsheet.

Does any of the PDF files in the list of test cases has one or more a file attachments? I can't say it for sure, but I think that VIP-Reader gives no information when file attachments are present.

None so far.

Thank you,

Laura

@lauracarlson
Copy link
Contributor

Hi @mraccess77 ,

Jonathan wrote:

We should also note the screen resolution used as well when zoom is used.

Thank you! I added a screen resolution column to the spreadsheet.

Laura

@lauracarlson
Copy link
Contributor

Hi @goodwitch and @alastc,

Glenda wrote:

My question, when should I do the zooming? After I've run the bookmarklet
(and the line height, spacing underneath paragraphs, letter spacing and
word spacing has changed)? Or do I so the zoom to 200% and then 400% on a
"clean" version of the page?

I updated the Wiki page with Alastair's suggested procedure.

Thank you both very much!

@KerstinProbiesch
Copy link

Hi @lauracarlson, one additional comment on the PDF-Tests with VIP-Reader: I think it is important to include PDF-Files in other languages, like arabic for example. These days I tried to open an arabic PDF with VIP-Reader. Please find the result in the screenshot attached. What I can't tell is if the VIP-Reader would display the text when the PDF would be accessible (whatever "accessible" means) and unfortunately I don't have any example for an arabic accessible PDF and in general no example for other languages than english and german. Therefore I can't say wether the problem is the technical quality of the PDF or the user agent.

arabic-pdf-vip

@lauracarlson
Copy link
Contributor

Hi @KerstinP ,

Thank you for your comment and attempt to test an Arabic PDF.

You wrote:

one additional comment on the PDF-Tests with VIP-Reader: I think it is important to include PDF-Files in other languages, like arabic for example. These days I tried to open an arabic PDF with VIP-Reader. Please find the result in the screenshot attached. What I can't tell is if the VIP-Reader would display the text when the PDF would be accessible (whatever "accessible" means) and unfortunately I don't have any example for an arabic accessible PDF and in general no example for other languages than english and german. Therefore I can't say wether the problem is the technical quality of the PDF or the user agent.

I'm not sure, Kerstin. Testing PDFs for this SC presents challenges.

Besides the international issue, VIP-PDF Reader has no adjustment for spacing underneath paragraphs. So that metric can't be tested. And it can be difficult to set a window size of 1280px by 768px for testing in VIP-PDF Reader. @mraccess77 previously asked about measuring viewport size for PDF readers for our tests. I used Free Ruler for the first 7. Check the VIP-PDF Reader Results tab in the spreadsheet. I included the VIP PDF-Reader's chrome but we may want to change that to just the content area.

Unless someone has a good idea for a PDF testing procedure for this SC (paging @awkawk ), one option would be, to not have this SC applicable to PDFs. From the work completed so far, it seems testing HTML documents for this SC may be more doable.

Thoughts everyone?

@KerstinProbiesch
Copy link
KerstinProbiesch commented Aug 22, 2017 •
edited
Loading

Hi @lauracarlson,

just as a side comment: The testing note in cell K2 seems to be the testing note for the next document and should be placed in cell K3.

I think that there are more challenges than already mentioned in this thread, like how to decide if a failure is a user agent issue or an technology issue? I'm thinking about writing a comment as separate issue for this SC on github with one or two examples.

Some thoughts about "to not have this SC applicable to PDF": What about the old "concept" of "until user agents"? (Yes. I know that because of a lot of good reasons "until user agents" was abolished with WCAG 2.0.). If there would be a way bringing in the user agent instead of focusing the technology in this (and probably other) SC and specifically for PDF it seems to be much better than having one or more SC which are not applicable for PDF.

@lauracarlson
Copy link
Contributor

Hi @KerstinP ,

You wrote:

just as a side comment: The testing note in cell K2 seems to be the testing note for the next document and should be placed in cell K3.

Fixed. Thank you!

I think that there are more challenges than already mentioned in this thread, like how to decide if a failure is a user agent issue or an technology issue?

Agreed.

I'm thinking about writing a comment as separate issue for this SC on github with one or two examples.

Adding them to the Google spreadsheet would be another option to document the issues. Then the testing results would be in one place. If you would like, I can add you as an editor of the spreadsheet. Just let me know. After we gather a few more cases, I will Wiki-fi the table and and it to Results of VIP-PDF Reader Tests for Issue 78 as I did for the Results of Bookmarklet Tests for Issue 78.

Some thoughts about "to not have this SC applicable to PDF": What about the old "concept" of "until user agents"? (Yes. I know that because of a lot of good reasons "until user agents" was abolished with WCAG 2.0.). If there would be a way bringing in the user agent instead of focusing the technology in this (and probably other) SC and specifically for PDF it seems to be much better than having one or more SC which are not applicable for PDF.

If we can't find a good and reliable testing procedure for PDF UAs, perhaps we should consider adding something such as "and the user agent has the capability to adapt them" to the current text. So the SC could read something such as:

If the technologies being used allow the user agent to adapt style properties of text and the user agent has the capability to adapt them, then no loss of essential content or functionality occurs by adapting all of the following:

But I would like to get more cases documented and advice from @awkawk and the rest of the group first.

Thank you,
Laura

@awkawk awkawk closed this as completed Aug 24, 2017
@lauracarlson lauracarlson mentioned this issue Sep 12, 2017
Closed
This was referenced Sep 25, 2017
Closed
Closed
@KerstinProbiesch KerstinProbiesch mentioned this issue Oct 5, 2017
Closed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@lauracarlson lauracarlson

Labels
~comment-text-spacing Integrated into Draft Guidelines LVTF
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
0