Success Criterion 1.4.10 Zoom content #343
Comments
|
@GreggVan do you have examples of pages that might be difficult to scale down to a 320 pixel viewport? A responsive website should be the default, heck, it is the default, it gets broken by CSS with fixed widths and heights. I can’t really think of a page that can’t be made to fit a 320 pixel viewport; 320 pixels is basically what the Web has been building for the last 10 years. |
|
<w3c-hat off> <w3c-hat on> <neutral-hat on> (The difficult life of a W3C fellow! :-D) |
|
A little bit of data, I tweeted a poll asking "What proportion of your sites launched in the last 3 years are responsive down to 320px width?". It got re-tweeted by several people, including one with a large following outside the typical accessibility circles. With 401 votes:
The replies were interesting in terms of understand 'why' people do / don't use responsive. Most indicated '100%', some questioned why it was a question. Of those that are not, it seems that the exact figure might be the issue. Some go further to 240px, some not as far (so probably answered most/some/none). The only reason given by anyone for not doing it was regarding IDEs, which is covered by an exception. I think it is fair to say that 'most sites' from the last three years are responsive, and would generally meet this SC with little or no effort. My organisation's site does, as do our clients barring a few sticky headers. Your site almost does, it works to 300% and just needs to sort out the header at 400%. The newer W3C pages should meet this already, and to be honest the older ones aren't that far off (even thought they would be conforming to 2.0, rather than 2.1). What we are missing is a logical, valid reason for not meeting it. We've covered the known ones in the exceptions, we're now in the position of waiting for people to raise 'unknown unknowns'. I suggest we close this, and open an issue when there is a known issue. |
|
this is very interesting !
Do you have any reference to this information?
Did they follow up on the approx 50% that did not meet — and determine what % actually were covered by an exception?
Data gathered from advocates can be rosier than fact — but if this is a fair view it is very interesting.
the reality of the other 50% though is key.
(and whether it is in fact accurate view)
Even if accurate though — this does say that half of the pages would be exceptions (or not able to conform)
either one raises question though … hmmmmmm
g
Gregg C Vanderheiden
|
|
As I said (and linked to), it's a twitter poll. I ran it, but I don't get to see who said what, or even who voted. I have a feel for who saw it (my followers, some other accessibility people, plus those of a well known designer with a much wider reach), but not who answered. As a starting point though (given there is no current accessibility requirement), it is a hell of a lot better than an equivalent for alt-text, headings, landmarks, or many other of the current WCAG 2.0 SCs. (An equivalent poll would be: "How confident are you that all your images have good alt-text? 100% sure | Most of them do | Some do | what's alt-text?"). Even assuming it is 'rosy', that's over 200 developers in easy reach who said every site they've done in the last 3 years has been responsive down to 320px. The W3C can do it, the tools we use can (although whether they will is another matter), we do, our clients do (or are in the process). There is no logical reason a site cannot (that is not covered by the exceptions), so unless you can find a valid use-case which cannot be met, please close this issue. |
|
lvtf |
|
FWIW, even CodePen (a well known online IDE) works on a 320 pixel viewport. |
|
Codepen seems to work ok on an iPhone but doesn't seem to work when zooming
in a desktop browser to make a 320px viewport - but this does show that it
would be possible for codepen to meet this. However, Codepen is far simpler
than the type of IDEs I am thinking of.
…On Wed, Sep 6, 2017 at 2:01 PM, Michiel Bijl ***@***.***> wrote:
FWIW, even CodePen <https://codepen.io> (a well known online IDE) works
on a 320 pixel viewport.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#343 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABpQP4aUfQEZ5DXoR3Ble_m2IqvFaOegks5sfwhEgaJpZM4PJpn->
.
|
|
https://www.textasticapp.com is an IDE as a mobile app. I agree that 320px is a design challenge, but it is possible to do. There seems to be no technical reason that prevents complex web applications from being responsive. |
|
two questions.
1) HOW doable is it.
2) How critical is it.
If we make 2.1 hard to do — and we ask for things that would be nice or really nice but are not SHOWSTOPPERS for people — then we make 2.1 adoption less likely — or make it so that people are likely to adopt 2.0 and parts of 2.1
That is my only concern. but a big one. Can this realistically be done ON ALL websites (since it is a requirement )
… On Sep 7, 2017, at 3:55 AM, Eric Eggert ***@***.***> wrote:
https://www.textasticapp.com <https://www.textasticapp.com/> is an IDE as a mobile app. I agree that 320px is a design challenge, but it is possible to do. There seems to be no technical reason that prevents complex web applications from being responsive.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#343 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJph3qgul6tNDodNcVeW5BDALSgC53e5ks5sf6FUgaJpZM4PJpn->.
|
|
Hi Gregg, I'm getting very tired of saying it is perfectly doable, with the exceptions included, it is perfectly doable, and indeed already done by most people! It is much less of an ask than many of the other A/AA SCs. Everyone on the WG who has recent dev experience thinks that it is doable (and do it already), so I'm turning this around: Find someone (or some content) that doesn't think it is feasible. I won't comment any further without some counter evidence. |
|
Grin - then you don’t have to keep saying it. I hear you.
But I was asking for evidence too. Your assertion that it is true is no better evidence than my question of whether it is. I was just asking if anyone had any evidence of it being true other than a twitter poll with mostly supporters responding. I am not asserting that it is or is not easy or possible. I was asking if anyone had any evidence that was not anecdotal. Has anyone done a sampling or a search for pages where it is not done and confirmed that is can always (reasonably) be done? That was my question.
At risk (with each provision) is that we add a poison pill. One SC that can’t be generally done. If we do - we risk either a) 2.1 is not adopted because of the poison SC. or b) people start picking and choosing which SC to include (WCAG 2.0 plus the following ones from 2.1) in which case they will end up leaving out many good ones we want.
|
I've provided many examples of where it is done now over our previous comments, across government, media, game sites, e-commerce (e.g. BBC.co.uk, Gov.uk, theguardian.co.uk, argos.co.uk). I've tackled examples from MichaelG and others of sites which don't do it now, but could. What we are lacking is any counter examples showing where it could not reasonably be done. Please find an example, or drop this. It is not a poison pill, many people (with dev experience) have said it is feasible at scale (with the exceptions). The working group was convinced, it is only you that is raising it now. I've done my part, we have yet to get any real counter-evidence. |
|
All website I’ve made in the last 5 years have been responsive, all of them. That includes things like:
I haven’t come across anything that couldn’t have been made responsive. I think the ±2 billion apps across the Apple App Store and Google Playstore also tell you a little something about what’s possible on smaller viewports. In addition, I’ve worked on far more projects where other success criteria weren’t honoured, like 1.4.3 or 4.1.2. Really, this is the least troublesome SC in the whole of WCAG as far as I’m concerned. If it were up to me this would be a Level A SC. If anything, this is an SC where most people’s reaction would be “Hey, that ones easy, I already do that, thanks W3C!” |
|
I think the question isn't only about can it be done for new website but how much it will cost to fix an existing website that isn't responsive. For me (even if I perfectly understand the need) it make no sense in term of design / conception perspective because purpose of mobile is also to offer less complex interface made to be used in a different context of usage. I know for example a lot of banking interface that offer a reduc scope of features on mobile. Maybe we can deal with that by having a level AA (without asking same content / feature) and level AAA criteria (with same content / feature) |
|
@goetsu wrote Maybe we can deal with that by having a level AA (without asking same content / feature) and level AAA criteria (with same content / feature) The issue is that I am forced into the less content/feature site on desktop with zoom and thus I have no way to access other features except by zooming out or if author provides link to the full site another way that is also accessible. This is related to the conformance claim proposed update. |
|
@mraccess77 yes that's why I say I perfectly understand the need but in my opinion if you don't have a desktop computer or can't use one for some reasons (for example my grandma only use a tablet because desktop computer are too complex to use for here) you will also always have access only to the less content/feature version of the website. it's not a discrimination based on disabilities but on context of usage and it's not the purpose of WCAG. Otherwise we need to have some SC when :
All thoses things are good things to avoid but they aren't accessibility issue but interoperability issue. |
I think this point came up before, my comment previously is that there are several good reasons not to provide a reduced set of features at smaller screen sizes (although obviously formatted differently). A small device does not mean a different context.
Using a small screen device (or zoom) doesn't mean you are mobile, goetsu's grandma is one example, people with cognitive issues are another (where simple tablets can be a necessity for some people), low-vision + zoom is another. Given that magnification without reflow is (as Wayne would say) not accessibility support, having zoom & reflow is very much non-discrimination, and having the functionality & content is part of that. The general industry is starting to recognise that for non-accessibility reasons as well. Going back to 2012 and the early days of responsive design, influential people were saying mobile != context, and you need to get all your functionality/content onto the smaller screens (preferably by reducing the content on desktop!). Overall it is only 'new content' that would be trying to conform to WCAG 2.1, no-one is being asked to updated all their legacy content straight away. Is it unreasonable that next time a company updates their site, they make it responsive and include all the content/functionality as part of that? A lot of our clients have already done that (across a fair few industries), my bank has gone responsive (and I can't see anything missing at smaller sizes). Can you think of an instance where it isn't feasible? |
does not mean same context either
Yes if they have decided to no have the same content / functionality or not using one responsive website but two different version evens if experts say that it's not the good thing to do.
I know at least 3 major banks in France not having same content at smaller sizes you can also look at www.lemonde.fr and mobile.lemonde.fr not having same content at all |
|
This is all great anecdotal info.
But for facts we need a systematic study with random sampling. And even then — the question isnt can MOST sites be made responsive but can ALL sites be made responsive -=- or more accurately — could they ALL be made to conform to the wording out or SC with reasonable effort.
I don’t know the answer. I am just asking the question.
And all the examples in the world of things that can meet the requirement do not answer the question of whether ALL can. It only takes one example to cause the SC to fail — unless we decide that that kind (those kinds) of website(s) should not be allowed. If we think it/they should be an exception - then we should make it/them an exception.
Again - I do not know if there is a problem with this one or not. But before we do this we should make some effort to find out — other than just looking at our own practice.
Why is it important?
1) we don’t want to outlaw some types of sites
2) we don’t want to poison adoption of 2.1 by including one or more SC that later can be shown to be unreasonable for some types of sites
3) we don’t want people to start picking and choosing which 2.1 SC they are going to include (e.g. 2.0 plus the following from 2.1)
my best
g
… On Sep 15, 2017, at 12:36 PM, Alastair Campbell ***@***.***> wrote:
because purpose of mobile is also to offer less complex interface made to be used in a different context of usage. I know for example a lot of banking interface that offer a reduc scope of features on mobile.
I think this point came up before, my comment previously is that there are several good reasons not to provide a reduced set of features at smaller screen sizes (although obviously formatted differently). A small device does not mean a different context.
it's not a discrimination based on disabilities but on context of usage and it's not the purpose of WCAG.
Using a small screen device (or zoom) doesn't mean you are mobile, goetsu's grandma is one example, people with cognitive issues are another (where simple tablets can be a necessity for some people), low-vision + zoom is another.
Given that magnification without reflow is (as Wayne would say) not accessibility support, having zoom & reflow is very much non-discrimination, and having the functionality & content is part of that. The general industry is starting to recognise that for non-accessibility reasons as well.
Going back to 2012 and the early days of responsive design, influential people were saying <https://karenmcgrane.com/2012/07/10/mobile-local/> mobile != context, and you need to get all your functionality/content onto the smaller screens (preferably by reducing the content on desktop!).
Steven Hay tackled the banking example <http://www.the-haystack.com/2012/07/09/great-works-of-fiction-presents-the-mobile-context/>.
Overall it is only 'new content' that would be trying to conform to WCAG 2.1, no-one is being asked to updated all their legacy content straight away. Is it unreasonable that next time a company updates their site, they make it responsive and include all the content/functionality as part of that?
A lot of our clients have already done that (across a fair few industries), my bank has gone responsive (and I can't see anything missing at smaller sizes). Can you think of an instance where it isn't feasible?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#343 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJph3jH1WR3l8XgEmmkVvZ_cIS97mk4Rks5siqeFgaJpZM4PJpn->.
|
|
@GreggVan wrote:
What would that show? It would show whether some sites have done it already, or not. It would not show whether they could. That is not a suitable approach.
It takes one example that could not reasonably achieve the SC, not whether a current site has done it or not. Also, I think it should be whether certain types of content (not covered by the exceptions) cannot reasonable achieve it, that's slightly different from "sites". Given that we've provided examples across domains, across industries, and I would add not just from our own practice, I think the onus is on someone to find an example that is not reasonable. Logically, re-flowing a layout is demonstratively easy to do, so the question is really what content cannot fit into 320px that isn't covered by the exception? |
|
@goetsu wrote:
Well, aren't we in the same territory as deciding to use components that need ARIA but not using it?
The question then becomes why? We have one client (large, nationally known in the UK) who has a separate desktop & mobile site, and the reason is because they haven't updated the design/templates for several years. They will be running on that system & templates (and WCAG 2.0) for several more years. Banks are notorious for that kind of slow movement (I think some still run core systems with Cobol!), but there is nothing about the content that couldn't conform. If a bank can do it (and I think there's more than one), why can't others? Also, I don't speak French, but the difference in features available from the mobile & desktop Le Monde sites don't appear to be that great. It seems to be missing the top bar from the mobile site, but the main nav is there, behind the 'hamburger' menu. The layout is different (obviously), but it looks like most things are available. I'd be interested to hear from an organisation (or their agency) that has other reasons for not going responsive, or removing features at smaller sizes (and not making them available in some way). I suspect the main reason at the moment is simply waiting for an opportunity to overcome legacy systems with a re-design. |
yes but ARIA design pattern aren't fortunately mandatory
many possibles answers to that question, can be for marketing/business, technical, organizational, performance, design, etc. Overcome legacy systems are far from being the only reasons. On at least two projects I'm currently working on they have made that kind of decision. One mainly for performance / technical reasons one mainly for marketing / design reasons (both of them international ecommerce website). On lemonde.fr you need to look more carefully a lots of third party content coming from partnerships aren't on mobile (weather, car sales, real estate, auction) and some category of content isn't there also like employment, smart cities |
If you use something that needs ARIA and don't provide an alternative, it pretty much is. I'm interested in what factors contributed to "performance / technical reasons", as we have clients who went responsive because of performance / technical reasons. Could you be more specific? Same for marketing / design, do you mean they wanted to provide separate sites? If so, taking one step back, what prompted that? Neither version of lemonde.fr allows for text-only expansion to (even) 200%, so we're failing if there is no option to accommodate low-vision users somehow. Adding some links through to the 'missing' items from the 'small screen' version does not seem difficult. |
I don't talk about ARIA but about design pattern that overused with negative impact on lot of users on situations where design pattern aren't needed but that another subject
for example if design and user interaction isn't done to be mobile first and you can't achieve to use same code for mobile and desktop you will end up either using some hidden / visible part of code that will increase page weight or using heavy javascript to change your DOM depending on media query
some user data analysis, some purely design and aesthetic reasons, some usability reasons (specially if the don't want to end up with too much content on mobile) Can also be for internal management reasons. Some company as different team to handle mobile and desktop. I don't say all this are good reasons or good things to do I'm only saying that it's existing and pretending that everyone can do otherwise easily and without high cost is a fairytale. |
|
There have been some changes to the SC with implementability in mind. The working group will be going through the CR implementation process to demonstrate the implementability of all the new SC. The W3C (and I think most of the WG) have been using responsive design and should have little difficulty meeting the SC. |
==================================================================
I think this is going to be too hard to actually implement and practice. But I commend the group on the care taken in trying to craft the language. The time and effort is evident.
My comment here is that :"
This should not be included at level AA unless all of the working group members can show how all of the pages on their organizations websites could be made to comply -- including all of the W3C pages.
I am not saying that they need to all be done before it is released, but they must be able to demonstrate how they could be done and ideally, have a commitment from their organization to meet the success criterion if it is passed.
The text was updated successfully, but these errors were encountered: