- From: Benjamin Love <benjamin.james.love@gmail.com>
- Date: Wed, 8 May 2024 20:22:10 -0700
- To: Karen Lewellen <klewellen@shellworld.net>
- Cc: Adam Cooper <cooperad@bigpond.com>, Michael Livesey <mike.j.livesey@gmail.com>, w3c-wai-ig@w3.org
- Message-ID: <CAEdsBL3SudhBXmu7teDVoPci0BCJLr3AucffRMMKn+43BZacdw@mail.gmail.com>
Admittedly, I’m not well versed in progressive enhancement in practice (vs well other approaches) but if the assumption is that progressive enhancement is potentially THE method for removing and avoiding barriers to access across time… Sounds grand. I have yet to find a true “foundation” to build upon over time to “easily” maintain access outside of following the *living* standards of HTML, CSS, and access-oriented JS. Validation of reading/presentation systems, and of course guided by end-user engagement. Because of the numerous / varied technologies at play in our individual and collective experiences with accessing digital media/information, it’s hard to imagine such a model in actuality. And given the diversity of other conditions/factors that may disrupt our ability to access, … I prefer to approach accessible design and dev as a problematic rather than a problem. Barriers to access can be “solved.” But accessibility itself cannot, will not (must not…). We do right, ethically, morally, to respond and be responsible toward, but barriers to access will never cease to exist given the diversity of human experience and the ever-variable conditions under which we exist together. Equality vs Equity. University vs Diversity. In some ways, such theoretical approaches to design/dev, while important (they invite discourse, testing, debate, etc.) can also function unfortunately as problematic “overlays.” Understand the fundamentals and functions of the technologies with which we interface, follow industry tested guidance, complicate rather than simplify your lines of questioning, and engage your users. On Wed, May 8, 2024 at 7:34 PM Karen Lewellen <klewellen@shellworld.net> wrote: > Adam, > Speaking personally? > There is no such thing as an average end user save in the minds of those > creating statistics. > There are hundreds of millions of people in countless locations all doing > individual things on the web. > The most surprising and best enforcement of the Lynx browser I ever came > across was in the New York Times, aimed at people wanting to cut down on > data use and bondage issues. not a single reference to accessibility at > all. > There are those who seek less clutter pages that load faster, clearly > labeled items, etc..and as I understand things, wCAG guidelines provide > that choice. across platforms, systems, and items used. > Which I hope helps everyone regardless of the body they have or the tools > they use. > Just my thoughts, > Karen > > > > On Thu, 9 May 2024, Adam Cooper wrote: > > > “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 > <mailto: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 Thursday, 9 May 2024 03:22:26 UTC