320px is mobile view, many sites drop parts of the content for mobile. I'm assuming that would not pass #813
Comments
|
it wouldn't pass if these sites dropped content without an alternative way to reach that content (e.g. dropping it from the page, but providing a link to another page where that content is present) |
DavidMacDonald
changed the title
|
I agree with Patrick on this. |
|
We certainly failed teams at my former employer because their mobile view omitted some buttons on mobile view ("because people wouldn't be doing that sort of thing on a tiny mobile screen") but hit me while zoomed in on a desktop. The media queries can't tell what device I'm using so even if their logic actually made sense (people would not want to try to do certain things on a mobile phone like deal with a large, complex dashboard), we couldn't allow it. |
|
I agree with Patrick on this. |
|
wondering though if "dropping just an intro text which can be seen on desktop, but not on mobile where only the heading is shown" will also fail. Please check an example of this at: https://www.ing.nl/particulier/financieel-fit/thema/inkomsten-en-uitgaven.html where the "Wat houdt u bezig?" list items 'drop' content when the screen is smaller / zoomed in. |
|
I also agree with Patrick, and that is what the phrase "without loss of information or functionality" was intended to convey. If you consider the 'thing' that disappears as either information or functionality, then it should fail. For @jake-abma's case, if you consider that the information conveyed in the intro text is also available elsewhere (such as the page you get through to), then I'd consider that a pass. NB: The language is very black and white, as it has to be for a content requirement. However, I think there's a little latitude in the use of the term "information". The intro text may not be duplicated in the following page, but if it is conveyed, that's ok. On the other hand, if that information could be used to differentiate the links / services (I'm not sure what they are), and it isn't available elsewhere, then that would fail. |
|
I do not think we should let developers drop any content at all - the moment we start doing that we a) get drawn into arguments like the one just above, as to whether something can be dropped or not, and b) the SC becomes un-testable. If the SC is to be interpreted to say some content is not truly "information" or "functionality", then who is to decide, and what criteria are they to use to decide it? If we leave it for the designers and developers to decide, then they will do more or less what they want. As the old saying goes, give people an inch and they will take a mile. It is also important to say how it can be hidden. Hiding content behind a button to reveal dropdown panel is fine. But hiding it on another page would need a link is also provided in the place where the content was, to that page, and the SC should specify that. Leaving low vision users to navigate through layers of menus and submenus before they see the lost content is of no use at all to these users. The "mobile view" is not just that, it is also the View low vision users work in all the time. |
We risk forcing people to make an overall worse interface for everyone then. There is a parallel to the keyboard accessibility of menus with drop-downs. Pre-ARIA, your main options where either:
As a solution for people, I prefered the second option.
I'm pretty happy with a dictionary definition such as "what is conveyed or represented by a particular arrangement or sequence of things." Is it conveyed? Yes? Great, done. |
|
I agree with Patrick, a fully functional mobile object that can be accessed
directly from a desktop or laptop is a way to meet the Reflow criterion.
This gives developers two ways, at least, to meet the criterion: Responsive
design or a fully functional mobile app that can be accessed on a desktop
or laptop.
It is true that many mobile apps will fail out of the box, but the
developers do have a reasonable choice. Bring the app's capability up to
match the web content for desktops or laptops or create a 320px case.
The Reflow Criterion is based on modern research that shows that
enlargement without reflow simply does not work to perform reading
effectively, a critical function of any web app. Just as the accessibility
world has to accommodate new change in web technologies, producers of web
technologies must accommodate to new discoveries in accessibility. It won't
be easy, but the working group has identified two well traveled development
paths.
Wayne
…On Mon, Mar 26, 2018 at 9:25 AM, Alastair Campbell ***@***.*** > wrote:
I do not think we should let developers drop any content at all
We risk forcing people to make an overall worse interface for everyone
then.
There is a parallel to the keyboard accessibility of menus with
drop-downs. Pre-ARIA, your main options where either:
1. Make the person to tab through every option in every drop-down, or
2. Only tab through the top (initially visible) menu, but make sure
that any option in the drop-down was also on the page you got to.
As a solution for people, I prefered the second option.
If the SC is to be interpreted to say some content is not truly
"information" or "functionality", then who is to decide
I'm pretty happy with a dictionary definition such as "what is conveyed or
represented by a particular arrangement or sequence of things." Is it
conveyed? Yes? Great, done.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#813 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AH0OF4q2II5aywmpsyvZQfgS53eKiXC-ks5tiRaQgaJpZM4S3Ay7>
.
|
I believe @guyhickling meant "drop" in the same way I meant it: completely omit it from the page and offer no alternative (like a separate page) for it. basically, making the small-screen version "dumbed down" (for "people on the go" who "only want to know the contact details and map to our offices" type crowd). In short, I think we're on the same page here in terms of making sure stuff is available one way or another, but never omitted completely. @WayneEDick this has nothing to do with mobile apps. this is purely a discussion about web content that reflows/adapts, and the fact that at 320px many sites wrongly assume that it's "mobile-only". and making sure that in this scenario content/functionality doesn't get dropped. |
Well, I hope so, but I had just made that interpretation and Guy disagreed. |
|
Thank you Patrick for explaining that, you understood me correctly. The point that was worrying me somewhat was where Alastair said :
because as soon as we start saying that then the question arises, "Where does that stop?" There are lots of cases where one person (maybe the developer) might say a particular item is not information and therefore not necessary to show, while someone else (e.g. the tester or accessibility auditor) would say the same item is information, and the user comes along and says they want to see it. You mentioned the example of an intro text. And take another example: the logo of the website's business owner. Some would argue a logo can be replaced by text, or even be omitted completely if the rest of the page mentions the company name somewhere (e.g. in the copyright notice in the page footer). It doesn't matter that we might all say that interpretation is wrong; if the SC leaves room for argument then people will do so, and where do we draw the line? That's why I think the SC must leave no room for leeway or interpretation (other than purely decorative content, I guess). As a result of this conversation we are having I think I was coming to the conclusion that it would be alright to drop stuff that is purely decoration (aka the concept of decorative images in SC1.1.1). Anything else should be kept. And that would be testable as well. But then, some low vision users would say they even want to keep the coloured decorations, they like the extra variety that the colours bring to the page. Come to that, I like the colours and decoration as well. Hmmmm. |
|
So I was looking specifically at Jake's ING example, where it has a descriptive sentence that disappears at smaller screens sizes / higher zoom levels. I don't speak the language, so I checked the page it links to for that text. It wasn't there, but I can't tell if that "information" in conveyed. Duplicating the text on the next page would be an obvious pass, but also a duplication for many people, which is what I meant by "worse". However, if the information is conveyed, it isn't an issue. Regarding 'decorative', can you think of anything that would count as information and is decorative? I feel like they are mutually exclusive? |
|
at its core i think @guyhickling's examples may be taking things too far into not being reasonably feasible. take the example of a logo being changed into just a text version of the company name on small screen, for instance. does the page still convey the same information and provide the same functionality? yes. it just makes a stylistic choice of not using the graphical logo but the company name. i don't think the intent of the SC should go as far as "it must look and feel the same, just still fit into 320px", as that goes well beyond the intention. even copywriting changes (e.g. making sentences shorter/snappier to make them use up less space)...part of me thinks at that point the small screen version is too different, but as long as the text conveys the same meaning, i could also see it from the other point of view that this would be acceptable. |
|
Yes, decorative and informational are mutually exclusive, so perhaps that might be the way (in the wording of either the SC or else the Understanding document) to make clear what might reasonably be dropped on high zoom, and what must always be kept regardless of zoom. |
|
We all know how to design user interfaces. They are built with target audiences in mind. We usually identify each audience with a few personas. So, when is functionally sufficient? We ask the following question for each persona? If this persona has low vision then are all of the intended functions for this persona available in 320px view. If functionality is available and comparably easy in the 320px version, then unnecessary information can be dropped. This testing cannot be automated, but it is easy to verify by hand. Wayne |
|
I’m reviewing the implementations and for Reflow we have one person passing http://www.bbc.com (http://www.bbc.co.uk) and one failing it. The rationale for the failure is that at 100% zoom there are articles that show up with a heading, an image, and a short text description/lede, and then when zooming in (change happens at about 250%) or making the window narrower (change happens at ~580) some images disappear and the short text description disappears as the responsive model is to have a simple list instead of a longer list with images and descriptions. When you follow the link it takes you to the same article, where all of the information is the same. The image used to promote the story isn’t on the page you link to, but the image isn marked with aria-hidden so it is regarded as redundant to the text (both the image and the text are in an anchor together). So the question is whether the text is needed on that page. I think that the argument that I would make is that the same information is available on the site and that the goal of the image+title+text is to get people to be aware of the article and to know that they can read more about the topic. Do we think that:
|
|
Same kind of example I added. Think I passed BBC last week. Alastair has a good rational and I totally agree, so following this it will pass. A good explanation will be fine but it will be a matter of some subjectivity. Decorative images are, well, decorative, so I see no problem there, but some images DO have alt text and what if that is not present in the next page...?! I say IF you use informative images which are NOT present at the next page and DO serve a purpose to understand the content they MUST be present. Otherwise they are probably only decoration and should not contain alt text. For instance I see an image of "Stormy Daniels" with the alt text "Stormy Daniels" and a heading with... "Stormy Daniels want... bla bla". Seems redundant and decorative BUT maybe they want it to be indexed... |
|
Hi @jake-abma @WayneEDick , @allanj-uaag , @awkawk and all, I agree it can be subjective. I think it can be a lot like evaluating text alternatives. From a journalistic perspective, the purpose of a lede is to summarize the most important aspects of the story. It's the best chance to grab a reader's attention and interest and get them to keep reading or click through to the rest of the article. Sometimes the lede may be redundant but sometimes it is not. In any event, people with low vision zoomed in at 400% will have loss of information and not an equitable experience (no summary of the most important aspects of the story) if it is not redundant. A couple of examples from when I tested http://www.bbc.com that I considered not redundant: Example # 1 at 100%:
Check: Example # 1 Screenshot at 100% Example # 1 at 400% fails to provide the summary paragraph for that article. The next bit of text is "Live" "Champions League and Europa League draws: Latest". Check: Example # 1 Screenshot at 400% Example # 2 at 100%:, the "News" section:
Check: Example # 2 Screenshot at 100% Example # 2 at 400% fails to provide ledes for any of the articles. Check: Example # 2 Screenshot at 400%: Would you consider these example lede sentences (media__summary in the markup) to be redundant to the "media_title"? Is it okay to lose the lede for people with low vision? Jim, maybe the LVTF can discuss this at our next meeting? Thanks, |
|
The key for me is whether you can access that info, that you are not disadvantaged. Something I've noticed is that reading is harder, slower with low vision. Reading less before your make a decision |
|
(Sorry, fat fingered the close button on my phone) ...a decision might be desirable. However, the key is that you shouldn't be disadvantaged overall, and I think having that info on the next page is an acceptable compromise. The other side of that is more scrolling if the ledes were all shown, also a negative There is some subjectivity, just like with appropriate headings or alt text. However, if the information is conveyed (somewhere) I wouldn't want to fail it. |
|
Yes, the missing content can be on another page, but I do think it is important that there should be a link to that page, somewhere close to where the content was originally, so that the user a) knows there is some information there and b) has a way to get to it easily. Just having the missing information somewhere on the website, on another page, should not be sufficient if the user may never discover it. - I'm not sure if this is going to included in the Understanding document or not? |
|
Hi @guyhickling
What I am having a difficult time reconciling is: what if the whole purpose of the missing content is to summarize what is on the linked page? Check the previous examples. People with low vision zoomed in at 400% will have loss of information and not an equitable experience (no summary of the most important aspects of the story). CC: @mraccess77 |
So will everyone on mobile devices, with no option to un-zoom. Almost by definition that content is not considered important enough. It isn't due to 'being mobile', it's due to real estate that the content is trimmed in one place, but available when you click through. If it were a complete feature that disapeared, or if the number of articles available reduced, that would be an obvious fail. But if a feature or content is trimmed down in one place, but still available on the site, I think we can consider that a pass. In fact, it's probably a better experience, at least in this case. NB: I'd like to say 'easily' or immediately available, but there's no way we can get that into the 2.x guidelines, that really is untestable and we've been through that discssion before. |
|
although I understand your where you come from @lauracarlson I do agree with @alastc on this and see that summary as supplemental and not core to understand the content. This is also why I should pass it if it's covered on the 'next' page. I also do think that is the 'accepted' convention / compromise being made, and the difference between mobile and desktop in responsive design. |
|
I don't agree that low vision users should just accept what is in the mobile view when they want to zoom on the desktop and are not on mobile. Since users even at 200% zoom are thrown into this view without choosing we have to evaluate whether the functionality is equivalent. The 2 questions we really are left with are
Today under WCAG CR #2 a user could be required to flip back and forth between alternative and standard pages to gain the same functionality. Is it more cumbersome yes, do users like it no. Does it meet the conformance requirements -- probably so if it's directly off of the page or on the same page. Maybe something to be addressed by Silver.... |
|
Isn't it so that IF the headings / links are not descriptive enough than that's the issue. So failing And if that's the case, what the exact relation with reflow... |
|
@alastc You still refer above to "everyone on mobile devices". Laura raised a concern on behalf of low vision users experiencing loss of information, and your reply was:
Mobile device users and low vision users are two entirely different groups of people. It just so happens that the layout low vision users see is unfortunately the mobile layout. It is far too easy to say drop some content from the "mobile" view and forget that this SC is actually designed for low vision users! It can result in decisions being made that are not good for the people that matter most. Mobile device users always have the option of going to a desktop PC to see the full content in its original layout. Low vision users do not have that option - they are stuck with the mobile layout becuase they need the zoomed version. I appreciate you understand that, but answering low vision concerns in terms of mobile devices is not helpful to low vision people. As you know I argued last year against the wording of this SC for precisely this reason. I was worried that people would read and interpret the SC as a mobile layout issue, and here we are not even at final release stage yet and even the people at W3C tasked with moving the SC forward are already in the mindset of thinking in terms of mobile devices. I can see people writing accessibility thousands of future articles on the web always speaking about this SC in terms of mobile device users. We will never get away from it. With this in mind I would like to ask once more that W3C go back to wording this SC to specifically mention 400% zoom for people with poor vision, and drop the references to 320 pixel screens. I think this is absolutely vital if people are ever going to understand this SC properly, and it is a matter of urgency to do this before final publication. If W3C people don't relate the SC to low vision users how can we expect the rest of the world to do so? |
|
Hi Jake, Jon, and all, @jake-abma wrote:
That was the rationale that I used to fail the BBC reflow implementation. How would a person with low vision know to go to the alternative if they lack the information that would have caused them to click through to it? I wonder if it is a "Catch 22? That is a "situation for which the only solution is denied by a circumstance inherent in the problem or by a rule." (definition) @mraccess77 wrote:
Yes. The functionality is there but the information is less. @mraccess77 went on to say:
Does the same hold true for missing information (in this case a missing summary)? If so, we have our answer. Thanks, |
|
@guyhickling wrote:
Of course. My point was about the content, and how important that content is for 'information and functionality'. If you don't provide that text (in that place) to half your audience (typical mobile usage on some sites), is that lede needed to convey that information?
You say 'unfortunately', but reflow is enabled by the CSS methods that create responsive sites. If there were not a mechanism for adjusting content & layout using media queries (created, or at least taken-up for mobile device support) we would not be able to have this SC at all. Authors have to create one site (or multiple forms of the site) for everyone, so we must have a compromise where the same information & functionality is available to everyone. From @mraccess77
Then from @lauracarlson:
I think so. I think it is a better situation than flipping back and forth between versions (you go to the next page to get the complete story), but it's the same principle. |
|
[Official WG Response] |
|
We'll need a common failure technique. "Loss of information and/or functionality when viewport is zoomed" |
|
And have any tests been written yet? - there aren't any shown in the published Understanding document for this SC. |
|
Hi @guyhickling You wrote:
A draft Allowing for Reflow technique is in the wiki. |
|
Thank you for the reference. Could I offer some additional steps to describe the test more fully? After the current 3 steps shown in the wiki:
Step 4 explains more clearly what it means when it says "no loss of information or functionality occurs", i.e. it explains "loss" compared with what? (If I were writing formal test instructions for other testers that's how I would do it.) And step 6 is important to mention, I think - loss of information can occur by other ways than by the developer deliberately dropping it. This step caters for accidental loss. |
|
Hi @guyhickling , I added your steps. Thank you! |
|
The WG decided on the above response, so we changed the text in the comment containing the proposed response to read "[Official WG Response]". Please confirm is you are satisfied with the response within 3 days. If we haven't heard a response by then we will regard the resolution as satisfactory. |
|
As there have been no futher comments, I'm assuming this is acceptable and closing the issue. For new updates to the Reflow understanding, I suggest adding a comment on #781 |
Is that an accurate assumption. The content can be hidden under show/hide buttons but not dropped for those views, right?
The text was updated successfully, but these errors were encountered: