It’s not just accessibility. I’ve last track of the number of times I’ve seen a mobile website with a table that extends past the right side of the viewport and zoom disabled. You can’t scroll, and you can’t zoom, so you can’t read the table.
For instance, normally sighted people or even people with "normal" nearsightedness, farsightedness, or presbyopia benefit from adequate contrast.
Text "size" is another thing because people should be able to control it, particularly given the wide range of different devices that are out there.
Depends on the individual case — I’ve seen entire projects get scrapped because it wouldn’t be feasible to make an “accessible” version. Some things just aren’t work for everyone and that’s okay.
For example, take buildings -- they typically have stairways, often as a fire escape route. However, stairways are not usable by everyone. Should we ensure that buildings have no stairways at all because there exist some people who can't use them?
To apply this analogy to web accessibility, consider WCAG 2.5.5 Target Size -- in order to pass, click targets must be 44px by 44px. Seems reasonable right? Try designing a desktop spreadsheet program with 44x44 click targets. It's basically impossible to do in a way that doesn't severely impair the design for people who can click smaller targets.
Extremes are always unreasonable, the goal should be to support everyone that you reasonably can. Nobody is telling anyone to make their tools work for the blind deaf and mute quadruple amputee - but that does not mean that it should be acceptable to completely ignore the variations in capability of people wanting to use your product.
> To apply this analogy to web accessibility, consider WCAG 2.5.5 Target Size -- in order to pass, click targets must be 44px by 44px. Seems reasonable right? Try designing a desktop spreadsheet program with 44x44 click targets. It's basically impossible to do in a way that doesn't severely impair the design for people who can click smaller targets.
Blindly following guidelines leads to problems, yes. But you can achieve the goal of making the spreadsheed usable for someone who has trouble with small click targets: For a desktop program you should consider adding efficient and discoverable keyboard navigation so that noone needs to click anything. This will help power users as well as those with fine motion problems. In general, a program, unlike a physical staircase, is also something that can dynamically adapt to the needs of the user. For example you could make your spreadsheet zoomable. For a desktop program it could be OK to rely on third-party (or platform-provided) zoom utilities - just don't write your program in a way that makes those impossible to use.
For buildings such dynamic adaption is not as feasible and so we make compromises that require some people to rely on others for help in incommon situations. But even there we should do what we resonably can - for in many parts of the world public buildings do have wheelchair-accessible entrances these days, even if the emergency exit is a stair.
A staircase isn't accessible, but still allowed. The accessibility is in an alternate implementation provided for those who need it.
A phone call is an accessible alternative to a website. US law says that the phone call must be offered at the same price as the website, for those who need it.
Exactly this -- some things just aren't going to be for everyone. If we truly wanted to make buildings "accessible", all stairways, and even printed signage would have to be banned, as there exists someone who cannot benefit from it.
I think what you just indirectly pointed out is that software is largely written by young, ignorant people who don't appreciate that everyone will get to experience presbyopia, and it happens sooner than you think. Maybe we should require product owners to be at least 40 years old ;-).
The web was not designed with accessibility as default. Instead it is a significant amount of work to make things accessible. Every project incurs huge cost in order to achieve it. I truly believe from an accessibility standpoint the web is simply broken. So sure, blame it on young programmers. But that's a poor excuse for where we are at today in my humble opinion.
This has got to be satire right? HTML is accessible by default, it's your horrible JS SPA frameworks that break thid. See [0]
I haven't perceived maintaining accessibility to be a big burden in the long term.
Interestingly the accessibility project forced me to raise my game on CSS/HTML, graphic design, etc. and probably had a bigger impact on my side projects than it did on my work.
Now multiply this times every web app in existence and the cost is quite large. A lot of this could be avoided with a better platform.
It seems to me the web is accessible by default. Write a plain old HTML page and everybody should be able to read it (assuming they have a computer to open it or a printed version).
People go out of their ways to mess this up by using fancy colors, fancy web fonts, messed up JS (frameworks), non standard components because it's cooler, disabling outlines, and so on.
Do you have examples where the Web is not accessible by default, apart from the by default unlimited line width which is easily fixable with one line of CSS?
Sure you need to use the right markup for the right things (and, no, <div> is usually not the right element for building a button or writing a paragraph, there are dedicated tags for those) but I can't see a way to avoid this.
IF don't fight it and if you respect semantics and progressive enhancement / beautiful degradation. You get so much by default: legible colors and font sizes, tabbed page navigation, alt texts, clickable labels, zoomable interface...
When you embrace the platform and its spirit, you get accessible results quite easily. But not a lot of people seem to embrace it. Many people seem to think "what to do for what I want to see" instead of "what to do for what I want to mean", and you lose if you do this. You need to get your meaning right and then decorate it carefully. You should not paint first. But that's probably not a web-specific issue.
What's more, building accessible things may make you gain time, by having a robust basis. It's not always a cost.
There are native UI frameworks where this is not nearly as big of an issue.
Too much freedom perhaps? Should you even be able to give a div an onclick handler?
What about inputs? Why do developers have to make custom inputs because the core ones are severely lacking? That's where accessibility goes wrong. Because core functionality is terrible and needs to be augmented with richer functionality (but terrible from an accessibility perspective).
There is something fundamental about this platform that does not naturally encourage good behavior. All you have to do is look at the evidence.
As an dumb little example, it's not even obvious that making a div a button is bad unless you know that it is. The platform doesn't guide you at all. It has an onClick handler the same as a button. Little attempt is made to differentiate the two from an API perspective.
I could give countless other examples, but I think I have demonstrated what I am getting at.
> Because core functionality is terrible and needs to be augmented with richer functionality
Well, yes, I agree with both of these points. I think I get your point in the end, and your examples are convincing.
I'd say the web platform is accessible by default but this is easy to break inadvertently and maybe not the ideal platform to build applications because despite its strong accessibility features, it's lacking for what we want to do with it today.
HTML being a format to write documents first and not applications probably does not help neither.
I remember back in the late 90's, and we decided to create a static website for internal use on a project. Everything was supposed to be quick and simple. We weren't after anything fancy, just something that worked.
We used Microsoft's whatever-it-was-called at the time for writing webpages. It turned out that the html produced required some special Microsoft fonts for the web.
Hells bells. The whole point of the Internet is interoperability. But no. We can't have that, can we Microsoft? We need special fonts. Interoperability? Screw that!
About the same time Java on webpages was a thing. We never used them, but I had seen sites that had. So the site had to download some Java craplet, whatever it was called, you had to enable it, plus of course you had to have Java.
Even when the web was still young, people had some really dumb ideas.
Then there was a fad that sites had to have some kind of animated intro on the front page. I remember seeing one for my bank and a recruitment site. No doubt that cost them a pretty penny.
Those early internet fads have died out, but today's websites are no better.
Why does my browser have to download fonts? I already have fonts! Just use one of those!
Anyway, that's me done. I'm off to shout at some clouds. Not the virtual clouds, actual real ones.
Frontpage, I'm going to bet. :)
I was an early user of Frontpage, shortly after Vermeer released it. A few months later, it was bought by Microsoft. Looks like Frontpage was absorbed and discontinued (https://en.wikipedia.org/wiki/Microsoft_FrontPage).
It was handy but I was just messing around with a very simple personal website and most of the time I'd just use Notepad or something like that.
>About the same time Java on webpages was a thing.
Guilty... I wrote a simple java applet to draw a polar plot of antenna radiation patterns. Later I added a calculator applet - after all, how handy would a simple calculator only a website away be?? I should have gone with the trends and converted both to javascript... but I did not.
>Then there was a fad that sites had to have some kind of animated intro on the front page
I remember the omni-present "site under construction" animated gif. As in, > 50% of websites had them somewhere.
Follow the link in this article (https://www.vice.com/en/article/9akenz/this-guy-compiled-eve...) for an eye-bleeding collection. Haha!
Yes. That sounds right.
It is on my mind because one of my hobbies is a cyberphysical artsystem that has a small book of design rules and presbyopia is what sets the limits on feature size. (You can't just tell people "hold the card closer")
https://gen5.info/$/XQ*42RXF-TLY:$B.8/
and is made of 8″x8″ cards. That's the first constellation I made, most of the output is either stand alone 4″x6″ cards or constellations. I'm working now on my third constellation from images published by Ukraine's MoD.
I've been dragging on my feet about blogging a manifesto for the three-sided cards, first because the system was changing by the day (it was a big thing for me to realize I could eliminate paper jams by printing the back side first) and then because I found hugo is good for anything except things that involve quantitative thinking or artistic sensibilities. I am still looking for a static site generator that's the equal of the subjects I want to blog about.
Circa 2008 I was working on a Silverlight RIA in a company that had MSDN subscriptions for everyone.
It worked just fine over the LAN off the server in our Ithaca office but when we demoed it for the people at the office in Rochester it took the application 40 minutes to boot because of all the round tripping.
That won me all the arguments I'd been having about excessive round tripping, getting that 40 minutes down to 40 seconds wasn't hard once those questions were resolved.
In the hands of a lot of people though Powerpoint is a tool for insulting the intelligence of the whole room.
If you want to understand without attending a presentation then what you want is a paper, or book. Those are very different formats.
I've given many presentations where I has to provide the slides, which were then repeatedly emailed as samizdat. Easy 10x as many people only read the slides, but a document would not have reached them at all.
It all depends on your audience.
Manager wanted to add a ton of content that they felt would be helpful. I said sure, and added it to an appendix with arrows, callouts, additional definitions, etc.
I then presented it to the CxO group -- we only discussed that first slide. I emailed the deck, and got comments back saying that the appendix was confusing but they loved how simple and clear the single non-appendix slide was.
I've always tried to follow the 4x4 rule: no more than 4 lines, and no more than 4 words per line. I've found icons and occasionally diagrams can be helpful in explaining more abstract concepts. Also, slide notes are used liberally.
One place I worked was veeery similar to what you describe here. PPT was considered docs of record since no one wanted to make formal memos and have those enter the control system. My approach had friction, since I would be extremely concise and direct people to the slide notes if they had questions. In this org, people were notorious for lifting slides from others decks for their own presentations (hence I would distribute as PDF to discourage this) since people would not field questions those slides might raise.
Just like native apps do...?
https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_...
It does have a default Page Zoom setting and it will remember Page Zoom changes per-domain (e.g. I have this site set to 115%).
There is a way for web sites to make use of iOS's Dynamic Type setting [0] to make text larger, but it's up to each site's author to include the requisite values in their CSS.
[0] https://www.interactiveaccessibility.com/blog/text-resizing-...
Browsers are native apps, so they already do that for websites.
From time to time people complain and say I need to "get with it", but not a single person has complained they couldn't read them from the back of the room!
Makes me think of the oxo good grips kitchen utensils. They were designed designed for people with poor dexterity and as a result have become easier for everyone, this has made them extent l extremely popular
The irony is you have to work to get this to not work. HTML by default will render just fine. Developers just can't resist customizing it so it doesn't work.
My web sites use plain HTML as much as possible. They're derided for being "Web 1.0", but they work, load in a flash, can be resized by the user, are legible, etc.
Even Apple went with pages that were light grey text on white with a tiny font. My eyeballs would just hurt trying to read it. This was a few years ago, maybe they fixed it, but I grew to avoid reading Apple's online docs because it was literally painful.
What is SO effing hard about drawing within the screen on web?! I can't tell you the number of times I've seen this issue. Just the other day I saw reddit's sign up form is totally broken on iOS, you have to swap between landscape/portrait multiple times and hope whatever garbage layout engine it uses redraws the button inside the screen.
I expect it's fairly rare for the employer of a web designer to give a shit what the site looks like on a phone, which means the designers don't give a shit either.
I see this "we can't afford to test on different resolutions" excuse with games that completely break for anything that is not 16:9 a lot. Don't target a fixed size. Don't target a fixed aspect ratio. Don't target a set of aspect ratios. Make your application responsive - you don't need different devices to test that responsiveness.
[0] https://firefox-source-docs.mozilla.org/devtools-user/index....
But, as you've noticed, with more complex UI (especially modals and toolbars fixed to the screen) it becomes more important that things are built to fit horizontally and vertically. It's not necessarily hard but it does take more thought to work out how things will shrink, grow, scroll, etc.
It’s because the web’s layout primitives don’t compose well. There’s no easy way to say “this is a full-width container and nothing inside it can go off screen.” As an obvious example, any descendant of that container can use fixed positioning and do whatever it wants. But there are subtler examples that are easier to fall victim to. The way to fix this is to built your own higher-level layout primitives and have conventions or tooling to enforce that you compose them only in approved ways.
overflow: auto;
Fixed positioning is you explicitly opting out of composability.
> The way to fix this is to built your own higher-level layout primitives and have conventions or tooling to enforce that you compose them only in approved ways.
No, the way to fix it is to look at your DOM and CSS instead of adding more abstractions with broken edge cases on top of your abstractions.
As soon as you put real data into a website, especially if the website is a CMS that you've handed-off to a _non-technical_ client, it's going to overflow every pretty, grid-based box.
Which makes the table content inaccessible. It _is_ an accessibility issue.
Here's the definition I prefer, that does not focus on "disabilities" (which many people equate "accessibility" with):
> When we say a site is accessible, we mean that the site's content is available, and its functionality can be operated, by literally anyone.
But it frustrates me to no end that a browser is no longer a "User" Agent and is now just seen as a... virtual machine for apps?
One tip: Don't try to install too many general filtering extensions (uMatrix, Privacy Badger, uBlock Origin, etc...) at the same time because they will end up fighting.
My addon list isnt that big either... it's just that I disable a lot of things as well, like webGL and other stuff. Suprising number of sites needlessly use these things.
Follow https://github.com/tridactyl/tridactyl/issues/2712 if you want updates when that's added. It would help if you could link to the website that hijacks ctrl-f in that issue :)
Even better, one chrome issue/bug report, had google devs on the tracker explaining how it's fine, and how each website should just fix things.
They were blathering on about how websites are broken, should be fixed, utter absurd.
The sheer, unmitigated gall, of saying "screw users" is beyond comprehension.
Google: unless you want another series of Professor Farnsworth posters around HQ, fix it!
For example if you're making a WebGL app, or if you're making a map zooming widget that needs to progressively load more local detail as the user zooms in on an area.
If you don't disable zoom, the OS and your zoom logic will be fighting over the pinch gesture.
iOS Firefox does have pinch-to-zoom, but having to use it every time I navigate to a page is tiresome.
iOS Firefox is a small niche choice and not the same codebase as desktop Firefox because Apple requires that you use their rendering engine. So I'm not sure it makes sense for Mozilla to dedicate the kind of resources to it to implement all the features I might want, and I don't have a lot of gripes. But as a datapoint in this thread, zoom is really important to me, and I miss it when it's not available. I shake my head every time I visit Google search results on my iPad because the text is so tiny.