- From: Adam Cooper <cooperad@bigpond.com>
- Date: Sat, 11 May 2024 10:44:50 +1000
- To: "'Karen Lewellen'" <klewellen@shellworld.net>, "'Michael Livesey'" <mike.j.livesey@gmail.com>
- Cc: "'Kevin Prince'" <kevin.prince@fostermoore.com>, <w3c-wai-ig@w3.org>
Karen, I'm not sure that Michael's professional grounding is of concern in forming his opinion on this list. what is of concern is that you have not explained how progressive enhancement is "designed to improve accessibility across populations" surely this is itself a 'blanket statement'? -----Original Message----- From: Karen Lewellen <klewellen@shellworld.net> Sent: Saturday, May 11, 2024 2:58 AM To: Michael Livesey <mike.j.livesey@gmail.com> Cc: Adam Cooper <cooperad@bigpond.com>; Kevin Prince <kevin.prince@fostermoore.com>; w3c-wai-ig@w3.org Subject: Re: progresive enhancement, and wcag guides? Michael, I am unsure of your professional grounding, but I am wondering why, in your opinion, discussing a process which by its definition is designed to broaden accessibility across populations, is counterproductive? It seems a debate, with those who spend their professional time on WCAG, or live with how the guidelines are implemented is part of why we are here. counterproductive is a blanket lane to make around what has been shown to benefit accessibility. Goodness, that would be like my claiming, not that I ever would, that braille focus is counterproductive, even if statistically less than 10% of the sight loss population are braille users. Or saying such because I do not use personally, knowing three recently blinded individuals who choose not to use Braille. Blanket condemnation does not educate, speaking personally. On Fri, 10 May 2024, Michael Livesey wrote: > Hi Adam, > > I agree completely re progressive enhancement being counterproductive, > but I won't say anymore as it might trigger a debate. > > Re WCAG making the UX better for everyone - in my opinion everyone > benefits from text that is clear to read, scrolling in one direction > only (reflow), clear focus borders, focus order being logical, semantic markup etc etc. > > I would argue that there aren't any non-disabled users who benefit > from text being cut off at different resolutions, overflow in y and x > directions, and focus order jumping all over the place. This is > especially the case when viewing websites on mobile devices and/or > adverse conditions such as sunshine on the screen. > > On Friday, May 10, 2024, Adam Cooper <cooperad@bigpond.com> wrote: >> And, Kevin, with the greatest respect, you seem to be more interested >> in > merely shotting me down rather than addressing my points. >> >> >> >> Yes, people with less than twenty-twenty vision ‘corrected or >> otherwise’ > may have issues with perceiving the relative brightness of items at > relevant distances, but this is what WCAG requires as a minimum as you > point out. >> >> >> >> The 4.5 an 7 requirements are intended for people with what is called > reduced and limited vision in Australia, but it is an assumption that > higher contrast ratios actually benefit people with a higher visual acuity. >> >> >> >> Relative brightness is not the primary factor in visual processing > disorders or neurological conditions such as dyslexia because these > are not necessarily affected by relative brightness, but hue as far as I understand. >> >> >> >> And your explanation of 1.4.1 in a graph has nothing to do with the >> use > of colour alone, but the low contrast of grey on grey. >> >> >> >> And, thank you for pointing out 3.3.7 – 2.2 is not as familiar as >> it > should be. >> >> >> >> My original question to Michael Livesey was about the ways WCAG >> improved > user experience (or usability?) for all. >> >> >> >> Your suggestion that WCAG somehow compels developers to go the extra >> mile > and make everything usable for everyone isn’t all that convincing > … nor is it anything I have seen in my twenty years in the business. >> >> >> >> My contention is that – and Benjamin Love pointed to this in a post >> in > this thread – is that notions like universal design or progressive > enhancement are sometimes counterproductive, are idealistic, and faddish. >> >> >> >> I am not discounting the prospect that conforming to WCAG has >> benefits > for people without a disability – I’d just like to see the evidence. >> >> >> >> >> >> From: Kevin Prince <kevin.prince@fostermoore.com> >> Sent: Friday, May 10, 2024 7:37 AM >> To: Adam Cooper <cooperad@bigpond.com>; 'Michael Livesey' < > mike.j.livesey@gmail.com>; 'Karen Lewellen' <klewellen@shellworld.net> >> Cc: w3c-wai-ig@w3.org >> Subject: RE: progresive enhancement, and wcag guides? >> >> >> >> You seem to be arguing against yourself and not reading the responses. >> >> >> >> Meeting 3:1 is a minimum and as someone with (corrected) 20:20 vision > anything significantly less than that becomes difficult to perceive, > read and parse – so that’s gonna affect dyslexics even more. Yes, > I’ll cope but I have a better experience purely for meeting the > minimum colour contrast whicjh is a WCAG checkpoint. Put me on a > cracked phone screen at the busstop in the rain, or in a high glare > situation and grey on grey does not cut it for anyone. >> >> Think about the 3.1:1 in terms of a background image – strasight >> away the > use of the contrast ratio means a sensible designer won’t put text > over complex graphics – that’s a win for the rest of us. >> >> Difference in colour may be aimed at people who cannot perceive >> colour at > all but it makes a huge difference to the usability of information. > Have you tried to read those graphs where every line is a subtle shade > of the same colour? Have you tried to efficiently parse that > information even with > 20:20 vision? Another win for all. >> >> Redundant Entry is WCAG 3.3.7 – you maybe need to refresh your >> knowledge > post WCAG 2.2. >> >> >> >> It seems as if you consider the standards in isolation when the >> effect > they have is holistic. If they do nothing other than get designers and > coders to consider the issues raised they have an improving value for > us all. >> >> kevin >> >> >> >> >> >> >> >> Kevin Prince >> >> Product Accessibility & Usability Consultant >> >> >> >> Foster Moore >> >> A Teranet Company >> >> >> >> E kevin.prince@fostermoore.com >> >> Christchurch >> >> fostermoore.com >> >> From: Adam Cooper <cooperad@bigpond.com> >> Sent: Thursday, May 9, 2024 3:59 PM >> To: Kevin Prince <kevin.prince@fostermoore.com>; 'Michael Livesey' < > mike.j.livesey@gmail.com>; 'Karen Lewellen' <klewellen@shellworld.net> >> Cc: w3c-wai-ig@w3.org >> Subject: RE: progresive enhancement, and wcag guides? >> >> >> >> CAUTION: This email originated from outside of the organization. >> >> >> >> As I said, only a handful of Level AA success criteria … >> >> >> >> For example, SC1.4.1 affects only people who cannot perceive >> differences > in ‘colour’ so there is no benefit to people who can perceive colour. > People with certain neurological conditions have difficulty > comprehending text written in certain hues like red, but WCAG has no provision for this. >> >> >> >> The 3:1 ratio for the relative brightness of UI components is >> sufficient > for people with twenty-twenty visual acuity for dimensions and > distances commonly used for the web. There is a significant population > of people who have better than twenty-twenty visual acuity. Increasing > the relative brightness of UI components does not NECESSARILY mean UI > components become more perceivable for these groups. >> >> >> >> And I am not sure as to which Level A or Level AA success criterion > treats the redundancy of re-entering text? >> >> >> >> In my view, It’s commonplace to make the claim that conforming to >> WCAG > 2.x universally improves user experience, but it’s harder to > demonstrate this in all cases. >> >> >> >> >> >> >> >> >> >> >> >> From: Kevin Prince <kevin.prince@fostermoore.com> >> Sent: Thursday, May 9, 2024 12:17 PM >> To: Adam Cooper <cooperad@bigpond.com>; 'Michael Livesey' < > mike.j.livesey@gmail.com>; 'Karen Lewellen' <klewellen@shellworld.net> >> Cc: w3c-wai-ig@w3.org >> Subject: RE: progresive enhancement, and wcag guides? >> >> >> >> Firstly, and probably most importantly, looking at the labelling and > keyboard issues leads to the designer seeing/thinking about UX > improvements – these often come about as patching the poor UX is > harder than doing it with a better UX. >> >> Captions, and transcripts, are a win for all. >> >> The use of colour means that a designer has to think about their >> choices > mindfully – that’s a visual improvement. >> >> Page Titled – get that right and it’s a boon to anyone who uses >> many open > tabs simueltaneously. >> >> Change of context – again a boon for all if that gets sorted. >> >> Redundant entry – you might enjoy typing but I don’t – great UX. >> >> >> >> And that’s just level A. >> >> >> >> At AA Contrast is a massive win for all, reflow (especially on >> mobile), > consistent navigation, flexible orientation, programmatically > identifying form field purpose, error handling all help to provide a better solution. >> >> >> >> Kevin >> >> >> >> >> >> Kevin Prince >> >> Product Accessibility & Usability Consultant >> >> >> >> Foster Moore >> >> A Teranet Company >> >> >> >> E kevin.prince@fostermoore.com >> >> Christchurch >> >> fostermoore.com >> >> From: Adam Cooper <cooperad@bigpond.com> >> Sent: Thursday, May 9, 2024 12:19 PM >> To: 'Michael Livesey' <mike.j.livesey@gmail.com>; 'Karen Lewellen' < > klewellen@shellworld.net> >> Cc: w3c-wai-ig@w3.org >> Subject: RE: progresive enhancement, and wcag guides? >> >> >> >> CAUTION: This email originated from outside of the organization. >> >> >> >> “In lots of ways though, it's worth pointing out to naysayers that > following WCAG also makes the UX better for non-disabled users too.†>> >> >> >> And what are these ways exactly? Level A success criteria are >> intended to > have minimal or no impact on visual design and only a handful of Level > AA success criteria could conceivably improve user experience. >> >> >> >> >> >> From: Michael Livesey <mike.j.livesey@gmail.com> >> Sent: Wednesday, May 8, 2024 3:39 PM >> To: Karen Lewellen <klewellen@shellworld.net> >> Cc: w3c-wai-ig@w3.org >> Subject: Re: progresive enhancement, and wcag guides? >> >> >> >> Hi Karen, >> >> WCAG is there to ensure anyone with any disability can have the same > usability as non-disabled users. >> >> In lots of ways though, it's worth pointing out to naysayers that > following WCAG also makes the UX better for non-disabled users too. >> >> Disabilities can be physical (unable to use the mouse), poor > sight/blindness, learning disabilities (ensuring the user knows their > position on the page and that things are clear) and many more. Mild > disabilities affect a significant number of computer users, WCAG isn't > just for a tiny few percentage of users! >> >> As to progressive enhancement, there is one failure condition in the > guidelines that points to this, but it is highly contentious and I > believe it has been under discussion to be reworked/removed. >> >> Many developers feel that supporting a CSS/JavaScript free website is >> not > tenable today and, in fact, to follow progressive enhancement would be > detrimental to providing the best experience for both disabled and > non-disabled users. (There are also old school devs who still believe > in it). >> >> I would suggest to follow the guidelines and use all available modern > tooling to give your users the best UX. >> >> >> >> On Tuesday, May 7, 2024, Karen Lewellen <klewellen@shellworld.net> wrote: >>> Hi all, >>> I am hoping that there is a link to well anything, guidance material >>> for > example, that provides wisdom around progressive enhancement design. >>> how, as I understand it, working from this foundation creates >>> broader > access, can, in theory, get one closer to wcag compliance? >>> I am encountering far too many folks who either believe that wcag >>> only > applies to sight loss, or that it *mandates* certain tools must be > used legally...and some of that comes from the u. s. state department. >>> Thanks, >>> Karen >>> >>> >>> >>> >
Received on Saturday, 11 May 2024 00:44:57 UTC