Replies: 33 comments 25 replies
-
|
Beta Was this translation helpful? Give feedback.
-
yes, CSS pixel was chosen because it's the one stable density-independent (e.g. it doesn't change from, say, going to an old low-dpi device to a retina/high-dpi device) base unit of measure. it is philosophically the same as other density-independent units of measure like in general, it's probably not interesting/important to try and "calculate" what 1 CSS pixel is in as there's no direct way for an author to determine at what physical size (as measured with a physical ruler on the screen) something will display, actual physical/display size is irrelevant. I would say though that in general, zooming does change what the actual size of a CSS pixel is when displayed (which is incidentally why, when zooming in modern browsers on desktop, the CSS pixel dimensions of the browser change, which then triggers things like media queries etc). |
Beta Was this translation helpful? Give feedback.
-
|
There are many cases, such as printers, ATMs, etc. where the physical display size is known, and unchanging (can't resize the content display view). I was wondering if this SC should be applied in such cases, as sometimes it is a simple small-sized LCD display and to get to different menu items/functions, a user may have to scroll right/left and up/down to access them. @samogami Maybe you can explain this more clearly where the application of this SC could be problematic. |
Beta Was this translation helpful? Give feedback.
-
|
It's not an issue to move down or scroll to reach other options - that meets the SC. the SC is about each item fitting in that sized view unless there is an exception. |
Beta Was this translation helpful? Give feedback.
-
|
I understand the discussion but think that @samogami 's point is being missed. I believe what we are asking for is an alternative description that provides a measurement for those evaluating a kiosk or display to determine if the font is "readable" and "accessible". CSS does not allow for this evaluation in the field (if we can not access the software in a closed system), so while it is adequate for anything being evaluated from a design standpoint, it is not adequate for evaluating the display without access to the digital interface. TLDR: Can we add a note for evaluating a set (non zoomable) display. |
Beta Was this translation helpful? Give feedback.
-
|
There are already existing requirements for closed products for text size in US S508 402.4 and EN 301 549 5.1.4 that are required for readability. SC 1.4.11 and 2.4.11 add additional restrictions that provide questionable accessibility to small screens (3.5 inches and smaller). |
Beta Was this translation helpful? Give feedback.
-
|
Before we tackle the effects of zoom, display resolution settings, or window size on the "effective" width of content, or talk about potential exceptions for Reflow (or other criteria) on particular platforms... Can the WCAG2ICT Task Force first confirm if we plan to use WCAG's definition of "CSS pixel" as the unit of measurement for screens and visible content? Proposal # 1: Use the existing definition of "CSS pixel" as written, changing "cannot be determined by content authors" to "cannot be determined by content authors when the physical display is not under their control". With this substitution, the definition is: CSS pixel It's straightforward to use this definition when the user agent or platform defines a unit of measure convertible to CSS pixels. It's no problem for apps on personal computers and smartphones, where all modern platforms define a density-independent pixel. So far so good. Otherwise, for platforms or closed systems where a physical screen is known, the WCAG definition tells us how to calculate a CSS pixel from the "viewing distance" of the physical screen. For such cases, proposal # 2: Let's say in a Note that viewing distance should be determined from product documentation where available, otherwise by evaluating the intended usage of the physical device. The Note can include nominal maximum viewing distances for wrist, handheld, desktop, and television, with corresponding physical size of the CSS pixel precalculated — similar to Table 5.1 in the EN (PDF page 27). |
Beta Was this translation helpful? Give feedback.
-
|
if you can't resize/zoom the content display view, then 1.4.10 does not apply/cannot apply |
Beta Was this translation helpful? Give feedback.
-
|
I'm sorry - I don't understand? The SC doesn't say anything about resize/zoom. |
Beta Was this translation helpful? Give feedback.
-
|
i clarified that throwaway comment more in the next point... |
Beta Was this translation helpful? Give feedback.
-
|
actually, let me clarify that throwaway comment some more. the idea behind 1.4.10 Reflow is that certain low vision users may have zoomed/scaled their display to 400% or more, resulting in a effective viewport size of 320x256 CSS pixels. Content not designed for that size originally must reflow, rather than causing bidirectional scrolling or being cut off. i think the situation is different when it's a device/closed system that has a screen set to a particular size, and where content/the application has been designed explicitly for it. it's then not a case of "the user zoomed, and now they find that they must scroll both horizontally and vertically / that content is cut off" |
Beta Was this translation helpful? Give feedback.
-
|
anyway, i've said my piece about this ill-conceived/written SC... i wish you all luck in trying to somehow crowbar this into some sensible form of applicability to non-web ICT |
Beta Was this translation helpful? Give feedback.
-
|
In Outlook for example, I resize the inbox and folder view and reading page - so I can resize views within the larger "window" of the application without resizing the window or display. |
Beta Was this translation helpful? Give feedback.
-
|
so you resized the viewports (treating those as separate content area windows) of the individual sections to make it apply. that's of course a special case of "user needs to zoom/resize/etc to actually get to the state where the SC applies". and normatively, it would only fail at exactly 320 CSS px width for vertical / 256 CSS px for horizontal |
Beta Was this translation helpful? Give feedback.
-
|
I'd say if people make it work at 320CSS then they'd probably going to do something that would allow it to work at other widths as well simply because the solution is a view resizing tool or similar or word wrap feature, etc. |
Beta Was this translation helpful? Give feedback.
-
|
a bold assumption. what if i needed no bidirectional scrolling at an effective width of 650px, but the developer only implemented responsive behaviour for 640px and below under the assumption it's then some "mobile/tablet" view? then it'll pass the SC, and as a user I'm out of luck... |
Beta Was this translation helpful? Give feedback.
-
|
i would suggest that (even for web content) it'll be extremely difficult to make an argument that for extremely complex applications (think photoshop, 3d studio max, excel ... big applications, in short) it's possible or desirable to have them fully reflow to such a small viewport size and remain actually usable/workable ... but that's a shortcoming/issue with 1.4.10 per se, not necessarily its applicability to non-web content |
Beta Was this translation helpful? Give feedback.
-
|
I'd interpret the apps like Photoshop may conform based on exceptions. |
Beta Was this translation helpful? Give feedback.
-
|
would you exempt the fact that photoshop has a very complex user interface (toolbars, panels, menus, sidebars, bottom bars, etc) under "Except for parts of the content which require two-dimensional layout for usage or meaning." the complex UI does not really require that specific layout for some intrinsic reason. it could well be argued that yes, theoretically you could make the entire UI for something like Photoshop fit in a 320x256 display. this will require an enormous amount of work (which app developers won't do), and still result in an application that is then practically unusable. much more likely that app developers will provide some alternative, very feature-limited and cut-down, version of their app for such small screen/viewport sizes. |
Beta Was this translation helpful? Give feedback.
-
|
The understanding doc says |
Beta Was this translation helpful? Give feedback.
-
|
that's only in the non-normative understanding document though...and is a bit of a flimsy (and again, oddly specific, as it only talks about "toolbars" not further/wider complexity and interface widgets) as an explanation. but ho hum. |
Beta Was this translation helpful? Give feedback.
-
|
Another beneficial scenario of the SC is that if I can resize content within an application to 320CSS pixels (regardless of text size) and then I use a platform level screen magnifier like Windows magnifier at 400% at a resolution of 1280 or above I should be able to read each block of content without requiring horizontal panning. This seems like it allows content to meet the purpose of the SC that others have stated without requiring the application to enlarge text directly but provide equivalent benefit to reading text that 400 times the size. |
Beta Was this translation helpful? Give feedback.
-
|
Adding one more question to discuss: How do we think about Reflow when user agents do not have available methods to reflow (wrap) content to fit the viewport? Is it the author's responsibility? |
Beta Was this translation helpful? Give feedback.
-
|
There are at least two scenarios where reflow (not just of inline text reflow, but a modified layout) may apply:
I think normatively, if no reflow happens and the app continues to show content in a narrow (320 px) view, it would pass. |
Beta Was this translation helpful? Give feedback.
-
|
I've read through most of the linked information in the issue, as well as the discussion so far. Here are my views of the 4 topics raised by @maryjom:
I think that the definition of CSS pixels works to any technology. It is a definition based on the user, and that depends on the viewing distance, that is known by hardware designers. We even have conversion from CSS pixels to physical millimetres in the linked document of CSS reference pixels: https://www.w3.org/TR/css3-values/#reference-pixel So, in my opinion there are no problems to use CSS pixels in non-web documents and software. In this context, I think that @mitchellevan 's proposal for modifying the note of the definition of CSS pixel is a good idea.
I agree with @mraccess77 here. Given the way that 1.4.10 is written, it doesn't really matter. In addition, we can add a note to explain that technology not allowing for reflow is equivalent to the exception: "parts of the content which require two-dimensional layout for usage or meaning" I provide proposals for notes in my replies to 3 and 4 below.
To me it is a combination of the capabilities of the technology (format of non-web documents) and the user agent. If they support some form of "reflow", then 1.4.10 applies. If not, then I consider that they would fall into the exception. Given that, I propose the following note: Note 1: For non-web documents, if the format of the document or the user agent don't provide reflow capabilities, then the document can be considered to be content which requires two-dimensional layout for usage or meaning, and would meet the exception of SC 1.4.10.
First, I think that 1.4.10 is a non-issue for mobile applications. Using the definition of CSS pixel, and the "reference pixel" explanation linked in that definition, we can make the following equivalence for the mobile viewing distance (which is equivalent to "arm's lengh"):
These are sizes quite similar to the physical size of the screen of a mobile phone, or at least the smaller ones. I believe that most mobile apps work without two-dimensional scrolling in such cases and would meet 1.4.10. As for desktop software, as long as the platform has window capabilities, then non-web software would have to reflow its user interface if windows are too small. Finally, is software is designed for specific hardware with small displays, it should meet 1.4.10 "by default" as a good interaction practice: having to scroll in a small screen is not good to any user. The only two things that remain open to me are (1) cases where the operating system does not provide "reflow" and (2) "complex" software such as photoshop, that have (several) toolbars. In both cases I think the exception of 1.4.10 would apply. So I propose two more notes: Note 2: For non-web software, if the platform software doesn't provide reflow capabilities, then the software can be considered to be content which requires two-dimensional layout for usage or meaning, and would meet the exception of SC 1.4.10. Note 3: Non-web software with complex user interfaces with toolbars can be considered to be content which requires two-dimensional layout for usage or meaning, and would meet the exception of SC 1.4.10. This is explained in the intent of understanding reflow. |
Beta Was this translation helpful? Give feedback.
-
|
@GreggVan In the meeting you were on queue with the following reminder: applies as written except change CSS Pixel to "xxx angle of view (equiv to 1 CSS pixel)" and ignore all references go phydical pixels Please expand in a comment in this discussion. |
Beta Was this translation helpful? Give feedback.
-
|
From Gregg's suggestion at end of call:
Then SC 1.4.10 Reflow adapted for ICT might be:
Note that the above is not literal word substitution. (The above (1) includes the calculation, and (2) resolves grammatical issues with a verbatim word substitution.) I presume Gregg's suggested "ignore all reference to physical pixels" would be a note to the glossary term? Or do we repeat that for each SC using CSS pixel. Do we need to add |
Beta Was this translation helpful? Give feedback.
-
|
Whatever the outcome, I think it is important to consider in the WCAG2ICT transposition exisiting and future options of larger devices (tablets) to show split screen views. Apps that are optimised for a full screen view on a tablet but do not reflow when shown on half the width (split screen) might be considered to fail 1.4.10 Reflow. I am not sure about this of course, just proposing the inclusion of (existing and future) split screen capabilities when "mobile" apps are rendered on tablets. |
Beta Was this translation helpful? Give feedback.
-
|
I am troubled by applying CSS pixels and the Success Criteria that use them to small (<= 3.5 inches) screens and closed systems and question if it will provide improved accessibility. There are already existing requirements in US Section 508 and EN 301 549.
|
Beta Was this translation helpful? Give feedback.
-
|
Again,We are not talking about hardware or closed systems. Just software and documents. If we are going to say that closed systems are out of scope - we don’t need to do this.Also if making this a hardware spec the spec should be angle subtended — with a note saying it is equivalent to 1 CSS pixel at such and such a viewing distance on such and such a screen resolution. The spec should be size and since a pixel is not any particular size - it would not be used in real life.For CONTENT and software however - we use CSS Pixel because there is no way to know what the size of the display is (unless your software reads not only the resolution but also the physical size of the display). On Feb 24, 2023, at 3:40 PM, Sam Ogami ***@***.***> wrote:I am troubled by applying CSS pixels and the Success Criteria that use them to small (<= 3.5 inches) screens and closed systems and question if it will provide improved accessibility. There are already existing requirements in US Section 508 and EN 301 549.
Using css pixel size does not work for small screens. Take, for example, a 20 mm x 20 mm screen. Meeting SC 1.4.10 with css pixels of 320 and 256, at arms length viewing distance (71 cm), would be 83.2 mm and 66.56 mm. The 20 x 20 mm screen is not big enough to not use 2D scrolling, and wrapping strings to have sufficient contextual understanding without obscuring part of the word could be impossible. Not all devices have platform assistive technology as an alternative means.
Another problem is that viewing distance is not always arm's length 710 mm (28 inches) and can be greater ~35 to 38 inches (813mm to 965mm)
Assumption that smaller screens will have shorter viewing distances (see Understanding Reflow) is not always to case for non-phone, tablet devices. Examples of where there might be a physical obstruction or installed in the built environment making it impossible for users to move closer to a screen include self-checkout devices, self-standing multi-function devices, and other kiosks.
There already exist requirements for closed systems in EN 301 549 and Section 508. EN 301 549 criteria 5.1.4 size of capital 'H' at arm's length viewing (710 mm) is 8.7 mm taking large amounts of screen area.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Regarding 3.5 inch screens - The iphone up to including the 4s all had 3.5 inch screens. The requirement is that blocks of content don't require 2 dimensional scrolling more than 320 CSS pixels (or in this case equivalent in degrees). If the screen is so much smaller then you would probably pass the requirement anyways This requirement doesn't require prevent screens with a single line that scroll to the left/right as that is only scrolling in one direction. Horizontally scrolling is totally fine if it's the only direction for the given block of content. |
Beta Was this translation helpful? Give feedback.
-
|
I've been trying to stay out of the WCAG2ICT space for now, but I did have a couple of points.
I'll tackle a few points in each of these 2 topic areas. 1. Software for closed systems/hardware devices1.1 Fixed-width displaysThere are many known examples of devices having a reduced, character-based display size. LCD displays on phones and many types of hardware devices are obvious examples. Let's think of a situation where it is a single-line, 20-character display, and someone writes an instruction that exceeds that length. There are several different conventions for bringing more text into view. They include:
I hope it is obvious to everyone, on reflection, that each of these is roughly equivalent to the end user in regards to interaction. There may be a few arguments made for interactions in specific circumstances with different users. However, none address the intention of Reflow, which is that as text changes in size (or the viewport shrinks), it elegantly reflows to fit the screen width so that the user does not need to horizontally scroll. The notion of horizontal scrolling in such a limited display type is pretty much meaningless. The user is always refreshing the viewport with a new 20 character set. I hope it's clear that the same basic challenge applies with any text-width display system, whether it's 1 or 4 lines. I hope it's also clear that where the user has the facility for rudimentary text resizing, the same basic restrictions apply. For example, some displays can make the characters double in width and height, so that a 2-line 20 characters per line display becomes a 1 line 10 characters per display view. This doesn't change the basic 'reload the buffer' interaction that happens. LCD is just one example. There are plenty of cases where technology is going to constrain author ability. And cases where it's going to constrain testing. I'm not sure how granular you intend to go for various specific current technologies before you just declare some things like Reflow N/A for closed systems software and software for hardware. 1.2 OS-restricted positioning and displayEven in a more traditional desktop app or native mobile app, the author has restrictions which do not exist on the web (assuming we ignore the browser chrome). Let's look at MS Word for a moment. Word does allow for the zooming of the document area. There are ways offered to display this that DO support Reflow, and ways of doing this that do not (particularly if you think about Print view, etc). Similar 'document', timeline or drawing areas exist in a variety of programs. Most of those do NOT allow for reflow for obvious reasons (maybe primarily to do with 2-dimensional presentation?). However, for dialogs, non-modal windows, menus, toolboxes, etc., for the most part, the app does not allow for any form of resizing -- in fact, looking at the Paragraph dialog in Word, the width of the dialog stays consistent regardless of application resizing (the other way of 'resizing' addressed in Reflow), so that when I reduce the main application's window width, the Paragraph dialog actually is thicker. ^ A screenshot showing that the Paragraph dialog exceeds the width of the Word application, and that it's information is unaffected by the display settings of the Document area. The author cannot support Reflow in this context. As well, for a native iOS mobile app, short of supporting Dynamic Type (which I would suggest is a Resize Text requirement more than Reflow) there is no way I know of for an author to reflow (except perhaps the very specific case of supporting it when meeting Orientation). |
Beta Was this translation helpful? Give feedback.
-
So, what do we get if we create a general "text wrapping" sufficient technique? Something that is technology agnostic? Or even split the non-web guidance for Reflow into text and non-text considerations? This is maybe a 3.0 mind exercise, but what if an SC read something like:
I can see wanting to work in some qualifications for the level of resizing (e.g., up to 200%) and possibly a minimum character width (e.g., where the width of a text area is 20 characters or more at default text size...), but ignoring all those qualifications, I think focusing on text reflow alone may allow this requirement to be better contained. And of course a separate reflow for non-text content could also be entertained. (Although I feel like it is less important?) |
Beta Was this translation helpful? Give feedback.
-
|
Good start Mike
…On Mon, Feb 27, 2023 at 6:03 PM Mike Gower ***@***.***> wrote:
In my experience reflow is important for non-web software, for example in
applications like VS Code where you are reading code or reading ebooks,
word processing documents, or whatever it might be etc.
So, what do we get if we create a general "text wrapping" sufficient
technique? Something that is technology agnostic? Or even split the non-web
guidance for Reflow into text and non-text considerations?
This is maybe a 3.0 mind exercise, but what if an SC read something like:
*Text Reflow*
Where text can be resized, it can be presented without loss of information
or functionality, and without requiring scrolling in two dimensions, except
for text content which requires two-dimensional layout for usage or meaning.
I can see wanting to work in some qualifications for the level of resizing
(e.g., up to 200%) and possibly a minimum character width (e.g., where the
width of a text area is 20 characters or more at default text size...), but
ignoring all those qualifications, I think focusing on text reflow alone
may allow this requirement to be better contained. And of course a separate
reflow for non-text content could also be entertained. (Although I feel
like it is less important?)
—
Reply to this email directly, view it on GitHub
<#101 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB6Q4F3HUCERK56IFP5GTKTWZVMITANCNFSM6AAAAAAUYKMX6I>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
@mbgower that's a good option for us to consider and I think that would work well for mobile apps. However, not all content needs to or can easily reflow. I think the trick will be to figure out how to scope what needs to reflow and exclude what doesn't need to.
|
Beta Was this translation helpful? Give feedback.
-
|
Thank you @mbgower and @WayneEDick for all the useful information about different hardware/software issues, and about how 1.4.10 was defined. As WCAG2ICT we cannot change 1.4.10 to talk about 400% zoom. I'm afraid that we can only work with the 320x256 "pixels". As I said in the last meeting, and was agreed with some of the people attending, the biggest issue of "CSS pixel" is the use of CSS in the term (and in its explanations). So my first suggestion for 1.4.10 would be to redefine pixel for WCAG2ICT (as we did for content). My proposal is to use the term "Device-independent pixel", with the following definition, note and example. I also suggest an abbreviation ("dip") that could be used in WCAG2ICT text:
With this definition, we could rewrite 1.4.10 as follows:
Finally, about all the "special cases" of strongly limited hardware or platform software, I believe that there should be a way to link these cases to the exception of requiring two-dimensional layout for usage or meaning. Hope this helps in the discussion. |
Beta Was this translation helpful? Give feedback.
-
|
I like the suggestion to move away from the term "CSS pixel" as proposed by @loicmn However, I'm still concerned that talking in terms of visual angles (or now device-independent pixels) does not harmonize with the existing guidance on text size in the US ADA (707.7.2 Characters), Section 508 402.4, and EN 301 549 5.1.4 as previously mentioned by @samogami We should be making life easier for people rather than creating a similar, but different, requirement that uses a different calculation to ensure legibility (or in this case reflow). I also think that we should add an explicit note about systems that do not support reflow (including some closed systems) being excluded from this success criteria. |
Beta Was this translation helpful? Give feedback.
-
|
I think CSS pixels and Device Independent Pixels are "How to Meet"
concepts. The question is what user output do we need to produce to ensure
accessible reading. We need 400% enlargement of text content with reflow
and full functionality. Ultimately any reader with low vision must have
access to that interface in order to read fluently. We need to state that
as simply as possible. A developer should be able to apply the zoom
for the platform and see 400% enlarged print or 1/4 screen width without
loss of readability.
Best, Wayne
…On Wed, Mar 1, 2023 at 11:22 AM Loïc Martínez Normand < ***@***.***> wrote:
Thank you @mbgower <https://github.com/mbgower> and @WayneEDick
<https://github.com/WayneEDick> for all the useful information about
different hardware/software issues, and about how 1.4.10 was defined.
As WCAG2ICT we cannot change 1.4.10 to talk about 400% zoom. I'm afraid
that we can only work with the 320x256 "pixels".
As I said in the last meeting, and was agreed with some of the people
attending, the biggest issue of "CSS pixel" is the use of CSS in the term
(and in its explanations).
So my first suggestion for 1.4.10 would be to *redefine pixel for
WCAG2ICT* (as we did for content). My proposal is to use the term
"Device-independent pixel", with the following definition, note and
example. I also suggest an abbreviation ("dip") that could be used in
WCAG2ICT text:
*Device-independent pixel (dip)*
visual angle of about 0.0213 degrees
Note: This unit is density-independent, and distinct from actual hardware
pixels present in a display. The physical size of a device-independent
pixel depends on the assumed viewing distance between the user and the
hardware.
Example: In the case of a mobile phone, the assumed viewing distance is
considered to be an arm's length, which is around 28 inches (71 cm). At
that viewing distance, the size of a device-independent pixel is 0.26 mm.
With this definition, *we could rewrite 1.4.10 as follows*:
Content can be presented without loss of information or functionality, and
without requiring scrolling in two dimensions for:
- Vertical scrolling content at a width equivalent to 320
device-independent pixels;
- Horizontal scrolling content at a height equivalent to 256
device-independent pixels.
Except for parts of the content which require two-dimensional layout for
usage or meaning.
Finally, about all the "special cases" of strongly limited hardware or
platform software, I believe that there should be a way to link these cases
to the exception of requiring two-dimensional layout for usage or meaning.
Hope this helps in the discussion.
—
Reply to this email directly, view it on GitHub
<#101 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB6Q4F6VT6X5THAHPAS7TVDWZ6OYLANCNFSM6AAAAAAUYKMX6I>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Loic's last comment sums up my current position on 1.4.10 for non-web. That said, if we are missing something important for users, then we need to do everything in our power as the WCAG2ICT task force to address it, and whatever we can't do here we need to push to the right place to get it done. To that end, @WayneEDick I would like to understand your last comment better:
I feel it's relatively straightforward to use 1.4.10 to achieve outcomes like those for non-web software targeting larger screens — such as desktop apps, tablet apps, some consoles games, kiosks with large screens, and smart TV apps. (In each case, to the extent they display lines of text with potential for wrapping.) However, I'm having a hard time visualizing the "400% enlarged print or 1/4 screen width" goal applied equally to non-web software that's constrained to smaller physical screens, such as native mobile apps, watch apps, and small point-of-sale terminal displays. How should we think about the user needs on small screens, and possible ways of meeting them (for a moment not limited to what WCAG2ICT can feasibly do with 1.4.10)? |
Beta Was this translation helpful? Give feedback.
-
|
Regarding 400% for mobile apps with a typical UI - it's been my experience that using platform settings like large text that at most 200% can be achieved without overly truncating. For reading blocks of text that are just text it could go up larger perhaps to 400% - but we have two different situations - text in UI and blocks of text for reading. They are both important but may need different requirements in my opinion. |
Beta Was this translation helpful? Give feedback.
-
|
Hi All,
Responding to Mitch Evans. First, I want acknowledge the difficulty in
addressing so many platforms and file structures. It is mind boggling, and
that is why I am no longer a member at 75. Now for my reasons for a goal
oriented success criterion.
Whenever we write a program we have a goal. It usually involves a map
from input data into output data. In our case the input data is all over
the place, but our output is an accessible interface.
We want to say that (within reason) whatever input data we are given, it
can be translated to the best possible user interface for a person with
low vision to read fluently with their eyes. Now, that is a lot of
variables, but the requirement of the output is fairly clear.
The content must meet the user's "critical print size" and it must reflow
to avoid 2-dimensional scrolling. We proved the necessity of the reflow in
the first LV Task Force.
Now what is this output content constraint? We also need the functionality
necessary for reading.
1) Critical Print Size: The universal way to describe this is by the angle
subtended by the print on the retina. Legge and Bigelow describe this well
in "Does Print Size Matter?' given on our LVTF bibliography.
2) Reflow with Readability: This means lines of text fit on the screen and
there are no controls obscuring or restricting the readability of the text.
These are things like fixed position headers and footers. Buttons that
obscure text etc.
Now the production of that output is the goal. The criterion should state
that accessible output can be produced for a given file type using the
enlargement mechanisms for the user agent for that file type. Hardware
limits may also apply. Note: I must face all complex user interface issues
on mobile phones using the blind interface. I'm not sure I'll live long
enough to see that change.
We can up with a calculation of 400% for CSS pixels because we could show
that by varying distance and size we could meet the needs of most people
with low vision who could read visually with that level of enlargement.
At the time, most screens were constructed so that at standard reading
distances for the device 12pt was equal to 16px.
Our dependence on CSS pixels was to give a method so that most people with
low vision could read visually. They could hit their critical print size
with reflow and full functionality. That gave us 400% with unobstructed
reflow. There were reasonable exceptions.
So, I think input data maps to critical print size + reflow +
functionality is the criterion. The numbers and the units used to
measure this are the method to meet this goal.
There, that's the best I can do.
Best to All, I miss you, Wayne
…On Thu, Mar 2, 2023 at 7:22 AM Jonathan Avila ***@***.***> wrote:
Regarding 400% for mobile apps with a typical UI - it's been my experience
that using platform settings like large text that at most 200% can be
achieved without overly truncating. For reading blocks of text that are
just text it could go up larger perhaps to 400% - but we have two different
situations - text in UI and blocks of text for reading. They are both
important but may need different requirements in my opinion.
—
Reply to this email directly, view it on GitHub
<#101 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB6Q4FY57BKGPF7IMAM2ZUTW2C3MHANCNFSM6AAAAAAUYKMX6I>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Overall consensus seems elusive for 1.4.10. It might help to find something we can agree on, and build from there. Assertion"There is a way to apply SC 1.4.10 Reflow to Android apps." Agree or disagree? DemonstrationThere may be more than one way to apply SC 1.4.10 Reflow to Android apps. I'll demonstrate one way. (1) Android can present apps at a width equivalent to 320 CSS pixels.The Android system describes its "Display size" setting as "Make everything bigger or smaller."
On the Android phones I've checked, setting the slider to its maximum yields a width equivalent of 320 CSS pixels as measured in a browser. From WhatIsMyScreenResolution.net:
(2) It is feasible to evaluate Android apps for pass/fail of the normative requirement.These phrases all mean the same things in Android apps as they do on the web: "Loss of information or functionality"; "without requiring scrolling in two dimensions"; and "except for parts of the content which require two-dimensional layout for usage or meaning." (3) Failures can occur.I've never seen an Android app fail 1.4.10 due to two-dimensional scrolling, but it's conceivable. More likely is loss of information or functionality. While the following is arguably on the edge of pass versus fail, it demonstrates at least the potential for an Android app to fail 1.4.10.
(4) It's reasonable to expect designers and developers to fix such failures.The rarity of failures in the wild supports this, as does Android developer documentation for layout and reflow. (5) Evaluating Android apps in this way supports a user need.If we choose this way of applying 1.4.10 to Android apps, it might not come as close to the critical reading speed goals as I would wish. That said, the system setting certainly make text bigger, as shown in the screenshots above. |
Beta Was this translation helpful? Give feedback.
-
|
I've folded in thoughts from this rich discussion and a meeting discussion into the proposal for 1.4.10 Reflow. Will discuss in the 20 April meeting. |
Beta Was this translation helpful? Give feedback.
-
|
Hello Group,
I really like the direction of the work. Before I work through the points
for discussion, I would like to say a few things about the need.
1. Enlargement with reflow is a necessary condition for reading with
impaired visual acuity. If a site or device does not enlarge with reflow
then its text is inaccessible by the fundamental meaning of access to
information.
2. I avoid small devices. I can't use them in a natural way. That has been
my experience. Android and IOS apps are just not for me.
I have debated to myself about getting a 15 inch Chromebook that supports
Android apps. I am a little afraid I cannot use it, but I think I'll try.
However, small screens are not for me. I think there are about 3,000,000
people in the US that share this point of view.
You are doing good work, but maybe people with low vision just can't use
small screens. I could be a mathematician, but I couldn't be a surgeon.
Best, Wayne
…On Thu, Apr 13, 2023 at 3:38 PM Mary Jo Mueller ***@***.***> wrote:
I've folded in thoughts from this rich discussion and a meeting discussion
into the proposal for 1.4.10 Reflow
<#98>. Will discuss in the 20 April
meeting.
—
Reply to this email directly, view it on GitHub
<#101 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB6Q4F43DLJYNUDVXXYTHUTXBB56RANCNFSM6AAAAAAUYKMX6I>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
@WayneEDick some folks like myself need small screens (with text enlargement) for accessing mobile UIs (not reading but app usage)- for me - an iPhone screen is more accessible than a tablet screen given limited field of vision. Enlargement of text for reading in my opinion is also different than enlargement of the UI. Reading for me is better on a larger screen. So it really depends on the task being performed what the text size and optimal viewport and viewing distance is. |
Beta Was this translation helpful? Give feedback.
-
|
Oops. Forgot that Jon.
…On Sun, Apr 16, 2023 at 5:18 PM Jonathan Avila ***@***.***> wrote:
@WayneEDick <https://github.com/WayneEDick> some folks like myself need
small screens (with text enlargement) for accessing mobile UIs (not reading
but app usage)- for me - an iPhone screen is more accessible than a tablet
screen given limited field of vision. Enlargement of text for reading in my
opinion is also different than enlargement of the UI. Reading for me is
better on a larger screen. So it really depends on the task being performed
what the text size and optimal viewport and viewing distance is.
—
Reply to this email directly, view it on GitHub
<#101 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB6Q4FZM5QLXL3LKWS3DPILXBSD7DANCNFSM6AAAAAAUYKMX6I>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
1.4.10 Reflow guidance has been developed and included in the WCAG2ICT First Public Working Draft. Thanks everyone for your input on this important topic. If you have comments on the WCAG2ICT guidance, open a GitHub issue. |
Beta Was this translation helpful? Give feedback.
-
|
I do hope this works better in ICT than the web. Important sites still fail
to function at 400%. I am careful that I keep my resolution at 1280x720 so
that the pixel ratio stay correct. However, many if not most important
sites fail to function after 400% enlargement.
I appreciate your work because most tablet apps fail to enlarge
intelligently if at all. They seem to assume a bigger screen just means
more room to cram content. The idea that one could want to use the space
like a cell phone that is big enough to see, just doesn't enter people's
head. I did hope that 400% enlargement would be emphasized more directly.
I'm not sure implementers will follow the wording, but you have made it
doable and have not compromised the intent.
There are very few criteria more important that this. I can mean the
difference between literacy and not reading.
Best, Wayne
…On Thu, Oct 5, 2023 at 10:06 AM Mary Jo Mueller ***@***.***> wrote:
Closed #101 <#101> as resolved.
—
Reply to this email directly, view it on GitHub
<#101>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB6Q4F5NQTUI2VPMNGK6USDX53SIFAVCNFSM6AAAAAAUYKMX6KVHI2DSMVQWIX3LMV45UABEIRUXGY3VONZWS33OIV3GK3TUHI5E433UNFTGSY3BORUW63R3HA4TENBUGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
There are currently two issues on how to apply and test 1.4.10 Reflow on non-web documents and software, plus the issue I created for the draft WCAG2ICT guidance. Here's links to all three so we can have a discussion in a single locale:
Some things to think about:
Beta Was this translation helpful? Give feedback.
All reactions