Why is a clickable div an accessibility nightmare when the button element has a lot of browser-preset styles that are harder to override? Assuming you put all the relevant state styles into place like :hover and :active and whatnot, what's the problem? Button elements are best used in a form. If you aren't submitting a form, what's the button there for?
That’s exactly it. With native buttons and links you get all the accessibility for free. If you attach events to non-interactive elements, you have to do all the accessibility work yourself. In a custom interface, a button outside a form is perfectly valid and the best choice for the above reason.
Yeah, no. If the only reason to do it is to accommodate poorly made accessibility software then count me out. That's bad reasoning and the 'correct' elements will change with the accessibility software.
Logically it should be the reverse. Screenreaders can learn how to detect all clickable elements instead of shoehorning a form control element into places.
I’m very sorry to hear about your experience. That really sucks. The fact we have a thriving browser ecosystem has got to count for something though. Could you recommend people use Firefox instead?
I have come to respect Apple in recent years for their focus on and promotion of accessibility within the industry. They are leading where others have often abrogated the responsibility to build inclusive products. We should celebrate this.
Therefore this headline made me sad. I appreciate sometimes drastic measures are required to persuade those with power to use it to change things, and it does sound like this bug has been around for too long. If Apple are serious about accessibility they need to fix it.
I have read that the relentless release cycle at Apple does lead to bugs like this never getting fixed. I hope this post gets upvoted enough that someone with influence sees it, and ensures that this one is different. Good luck!
>They are leading where others have often abrogated the responsibility to build inclusive products. We should celebrate this.
What "others" are there except Microsoft Windows and Linux - both also having plenty users here saying that they see those OSes as ahead of Apple? Seems to me that at best Apple is on par, not someone to celebrate above others.
I was thinking about when Google launched their progressive web apps page a few years ago with the Accessibility section marked as ‘coming soon’ – not good enough!
I was also thinking about the marketing oomph Apple have put behind innovative accessibility features over the last year or so: https://www.apple.com/accessibility/ It’s great to see a company’s accessibility page being more than a dry statement of conformance with WCAG 2.1. As far as I could tell, they were the first major tech company to take a lead on this.
They clearly do need to do more work. As do we all!
What I love about this is how PHP and JavaScript had basically the same syntax (minus a $ symbol here or a var keyword there), and then NodeJS was like, but we want to run JS on the server! And now, 15 years later JavaScript has finally caught up and it’s basically the same as PHP, but with more acronyms and a steeper learning curve (to be fair, streaming data from server to client components using suspense is cool). I’ve been using NextJS 13 and I love how it makes SSR as easily achievable as it always was with PHP and always should have been. I’d recommend it highly.
In fairness, PHP prior to v7 was either a dumpster fire or a dirty bomb depending on how far back you go. When folks called it a fractal of bad design, it 100% deserved it, and folks rightly went looking elsewhere to solve their problems.
PHP is a phenomenally better language today, and folks really should take another look, but let's not pretend it was always anywhere near as good as it is today. Not by a long shot.
Also, don't judge NodeJS based on the React ecosystem. The sheer mass of APIs and wrappers needed to get a React-based system running is no one's fault but the React community. Stockholm Syndrome at its finest.
PHP has as much client-side rendering as React SSR does.
I think the sleight of hand that is happening right now, and that gets people a little confused, is that React is shaping up to be this thing that handles both front and the backend where other solutions can't do that. Sure – but it does that by overloading and complicating what React once was (neither of which per-se negative, I think it's just an apt description of what is going on)
Where other solutions might have abstracted the frontend part into a thing with a different name (or not bother doing it at all) React chooses in a rather unprecedented move to call it all just... React (well, there's Remix and such, but alas). Which is fine, as long as you understand that this new "React" will now probably lead to "React Frontend Dev" and "React Backend Dev", because the work and the complexities that these rolls entail did not just disappear by rolling it into the same name.
It's not entirely clear if architecturally there are going to be more benefits than footguns, but I think it's cool that they are trying.
React borrowed these concepts from Solid, SvelteKit, and Remix.
Not that there’s anything wrong with that. It’s pushing things forward. (And by forward, I mean, yes, also a little backward. We had server-side dominance with php, etc., then frontend-only with Vue/React… Now we finally get to serve our cake and consume it, too.)
I sometimes hear snarky comments about the proliferation of all these frameworks. But here is the tangible benefit of that “competition.” (Really more cooperation than competition)
More like React scrambled to add a feature to check a box in a comparison chart with the upstarts no matter how cumbersome or disruptive the API changes ended up relative to existing codebases.
The new frameworks were poised to eat React's lunch, they knew it, and they needed something quick to hold back the rising tide.
They may succeed, but only due to inertia, not a better/cleaner solution.
I had my own server side component system in PHP, 20 years ago.
And when the marvel of AJAX happened I enabled some of the components to be requested separately by the client code, rendered and sent to the client to replace the part of the website they occupied when they were rendered when the page was served initially.
Technically it wasn't client side rendering but it wasn't far from it.
And for actual client side rendering I experimented with compiling my HTML templates into XSLT and sending XML with data instead of HTML to the browser and letting it render it to HTML using provided XSLT. Because it was blazing fast when compared to JS at the time.
So, yeah, I guess thank you industry for coming around to what some twentysomething years old made just to build some websites for his freelancing.
I'm sure that React is engineered way better than not only what I achieved, but also what I could ever hope to achieve. I'm not against React. I'm just saying that it's an implementation of really natural (good?) old ideas. Just in JS.
> And when the marvel of AJAX happened I enabled some of the components to be requested separately by the client code, rendered and sent to the client to replace the part of the website they occupied when they were rendered when the page was served initially.
I did the exact same thing. I made a page with a table that was fully rendered server side. Any change in the display, such as pagination, sorting or filtering would trigger the same PHP code that returned a HTML fragment. The Javascript for that was easy. Just send an AJAX request to the server and replace the <tbody> element with the new content.
The PHP code itself was separated in components which made it easy to share the rendering logic for the initial page and the page used for the AJAX request.
React solves this in a more convenient way, but I am really surprised that we had to wait until 2023 before it happened.
I never liked NodeJS; on the one side it was innovative in that its concurrency model allowed for faster back-ends, but a lot of the features of existing back-end languages like Java and PHP were still missing, so a lot of patterns were re-invented, the language itself needed years to get to the 'safety' levels that Java already had and PHP was working towards, and proven and standardized technology like XML and the contractual guarantees it could give were discarded because it was heavy and JSON was better because it was human-read/writeable or something like that.
I feel like we lost a lot of time and effort by ditching XML. I mean documenting a REST/JSON API is still painful. While 20, 25 years ago you could already generate your data models and a parser for your XML payload. I still don't know what was wrong with XML. Yeah it was a bit heavier on the line than JSON, but that's a fixable problem - using compression, or use EXI (https://www.w3.org/TR/exi/) to turn it into a binary protocol. I don't know if EXI ever became a thing, but at the time I was quite exited about it knowing how much XML was passed around.
EDI never became a thing. One of the greatest selling points of HTML/XML/JSON is that they are human-readable. Even if gzip compressed, most tools will decompress automatically and show you the raw text.
So the tooling nor library support never came for EDI (i.e., Chrome, libxml, etc.)
Also, if you really wanna go full-throttle binary for speed, size, etc., you probably don't want something heavy like XML anyway.
I do think a lot of the original reasons why NodeJS was created has been lost, since at that time, non-blocking IO created some great performance gains. In many "modern" developer minds, it's now relegated to a dumb tool to spit out JSON or host a toolchain.
Worth pointing out that the em is an ancient unit of measurement and represents the width of the letter ‘m’ in a given font, and rem stands for ‘relative em’ - as in relative to the body. I have always found this appreciation has helped my understanding.
em is an arbitrary font metric that actually has nothing to do with actual character measurements, and not even a particularly strong correlation. I measured the width/advance of m glyphs at font-size 16px in a handful of the fonts I have installed, and got values between 8.88 (Advocate, condensed) and 15.59 pixels (DejaVu Sans). The two monospaces I had were around 9.6. The regular serifs and sans-serifs were 12.01–15.59 with no obvious rhyme or reason. Some have different aspect ratios which lead to this, and some are just smaller or bigger than others at particular sizes by ten or even twenty percent. Font sizes are truly just fairly arbitrary numbers. (But there is the ch unit, which is actually based on font metrics: the width/advance of the 0 glyph. Also ex, the height of the x glyph.)
rem is root em, which for practical purposes means “not relative” in contrast to em, which is relative to the current or parent font size, depending on where you use it. (Sure, rem is still relative to the root font size in most places, and the initial font size in the root font-size declaration and in media queries, but it’s… less relative than em, if you will. Certainly thinking of it as “relative em” will lead you wildly astray.)
The default line height is defined by the font (and the browser may influence it in other ways too?), but it’s distinct from the em. (It’s easy to try in a browser. I see values like 18.78px and 19.33px and 21.67px on my 16px text.)
Not working on Firefox for iOS. Can anyone else confirm this to be the case? Looks as though Firefox for iOS does support ‘prefers-color-scheme’ media query.
I can confirm that dark mode does not work on iOS Firefox.
I tested it a month ago and figured an update was coming soon. But I just tested it again on iOS 13.1 with everything up to date and still no luck. Safari works as my control.
This site didn't load properly in Firefox on a Samsung Galaxy S8 just now, and the accessibility section is "coming soon". I'm sorry Google, but if you're letting key basics like this slip... Accessibility is not a bolt-on for afters, and chrome isn't the only web browser. Deep down you know this too. Those who preach are held to higher standards, and you've let yourselves down badly here.
I can't replicate it in private browsing. I'm not running any mobile extensions and my internet is as good as it comes. First time I loaded it the blue line at the top was there for ages. I was scrolling the site for a good 20 secs marvelling at the irony of a site teaching performance not performing. It felt like something to do with the service worker not working. The cookie notice only appeared after I refreshed. Now it works fine, and loads fine each time. So it was something to do with the initial caching of assets.
And yes, the accessibility section coming soon sends the wrong message very subtly but powerfully. It's something we all need to be better at, and when you've got the resources of Google there just isn't any excuse. Those two small words on that missing section quietly absolve us all. Because if Google can't do it right, why should we? It just isn't good enough, so yes, they have let themselves and our community down. I know they're strong words, but someone needed to say it.
> The cookie notice only appeared after I refreshed
Maybe it's a geo thing. Are you in Europe? I see no cookie notice (US).
> I know they're strong words, but someone needed to say it.
Eh, it needs to be there but don't throw the baby out with the bathwater. It's apparently in "beta" and according to this hn thread robdodson is working on it, so odds are the accessibility section will be handled just fine.
Regardless
> Those who preach are held to higher standards
is a bad take. You can criticize a tutorial site without standing on such a flimsy soapbox.
takes way too long to load. if i wasn't visiting to give you feedback i would have clicked away before seeing anything about you, left only with the memory of an albeit pretty loading animation. Also the text of the list in the about section overflows the edge of the page, making it unreadable. Am using Chrome on a Mac.
