extra88
extra88 on Hacker News
Absolutely not, unless you're using your hobby site to learn Drupal.
I'm most familiar with the U.S., where it's not a requirement. Europe is the only place where I've heard there might be a requirement to honor a device's color scheme, I think it's very unlikely it exists anywhere else.
If a site honors the dark/light setting, I don't know what accessibility need would be served by being in the opposite mode for that one site. Having a toggle to meet preferences, yes, need, I don't know.
Everyone thinking about 2-state vs. 3-state controls is automatically honoring the device's color scheme setting. The controls are an extra to let users choose to
not use the device setting on a particular site.
Rather than each site making its own design for such a control, I wish browsers would make it a per-site setting users could use.
Honoring the dark/light color scheme set on the device
might be a requirement in some cases (I haven't seen a straight answer about it for the EAA) but it is a good accessibility practice.
Including a toggle in an app/site UI so users can choose to not use their device setting is an extra.
I can see it, the Sign Up dialog has a Close button.
Sure it does. Open a modal <dialog> using <button command="show-modal">.
That's not what it's for, that's solved by showing the link when it's focused.
My guess is there was a desire to make Find-in-page automatically expand <details> elements and someone realized they could make it also work for custom disclosure widgets by giving the boolean attribute `hidden` an optional value.
That's fine, everything doesn't have to look the same everywhere. It does matter when there's functionality a site relies on but it's not available in one out more browser/OS combinations.
CSS now also has `reading-flow` to instruct the browser to change the reading order to match the visual order created by Flex or Grid. Unfortunately, not all browsers support it and it has some limitations.
All current browsers support anchor positioning including popover buttons being the implicit anchor. However, the anchor positioning polyfill does not support this, it requires an explicit anchor-name.
It is significant because cancer is much more detectable today than in 1956-80, both because of better tests and more testing being conducted. In that earlier era, if you knew you had cancer, it was likely because it was already bad.
I also expect that of the 39.2% of the population, the cancer is diagnosed much later in life than it was for the 91 movie crew members, I doubt 41% of the crew was over 50 in 1956.
On iOS, the filled-in ones are all in colors set by the font but in macOS Safari they inherit the text `color`.
I have a personal site on a shared host that was recently suspended for excessive CPU use caused by incessant AI bot crawling. I don't have a problem with crawling per se, there's just so many and they're so bad at it.
Same.
Also, proper names should be excluded entirely; the only "Advanced" one I got wrong was a place name.
That's not what your original message was about and please don't invent quotes that are not what I wrote or anything like what I wrote. You wrote:
> The iTunes movie store is not friendly outside of the Apple ecosystem. Making the entire idea not really affordable since you need a expensive electronic device to utilize it sanely. Might as well find another way to get to it at that point.
I pointed out that buying a movie from Apple does not require an expensive device and does not require buying any hardware from the Apple ecosystem.
You ignored the facts and kept going on about having to buy expensive Apple hardware, which it isn't and you don't.
You moved the goalposts by requiring not only that purchases not require hardware that's expensive or from Apple, you added that it must not be revocable or streamed and must work on Linux.
I am not advocating for the iTunes store or any other source for buying media, I lost interest in owning TV or movies long ago, I was just providing factual information about what doing so requires.
You're moving goalposts and ignoring what I wrote. An Apple TV box is not expensive and you can use even cheaper streaming devices to buy and watch instead.
MSRP of an Apple TV device is $129. The iPhone's market share in the U.S. is already over 60%.
But neither matters because the Apple TV app is available on basically everything and can be used to buy movies.
https://support.apple.com/en-us/119890
How would you avoid that? How would someone exploit that information? The whole point of the other auth means are that they're more secure.
> many sites that have a form with only one input don't automatically focus on it.
That's reasonable to do when that form is the reason a page exists but otherwise it's best to not mess with the user's focus.
There is no pair for the enterprise users signing in with their company's SSO or those using Passkey.
I think what some sites do is have a visually hidden, not required password field that a password manager can fill in. If it's not a password-based auth, the flow goes to the next step but if it is, it reveals the password field which may already be filled in.
None of that legal complexity has anything to do with putting "aria-labels on absolutely everything."
> And for the attacker, they only need to find one case of violation - while you need to be correct 100% of the time.
I don't know how European regulators work but even in the litigious U.S., this is not true, at least not in the courts. However, for small businesses, which are more likely to be targeted by the trolls, the cost of proceeding far enough to get a suit dismissed is burdensome. And in the EU, I thought individuals couldn't bring cases to a judge, they have to complain to a regulatory body that can decide whether proceeding is warranted or not.
> implement defensive overcompliance far beyond practical usability requirements
This is like complaining about having fewer grams of rat turd in your flour than legally mandated; "Oh no, we made our product too good!"
In practice, building "reasonable software" has never included making it work for people with disabilities, despite WCAG and the web standards themselves existing for decades.
They have defined what exactly needs to be done to be compliant, it's basically "meet WCAG 2.1 Level AA" with some additions. WCAG has already been the de facto standard for decades.
I don't know what accessibility tools you're thinking of. If you mean assistive technology software like screen readers and voice control, yes, too often they fail to do what they should even when web standards are followed but at least as often the fault is with the web browsers (assuming the page code is all technically correct).
I'm not aware of any accessibility reasons to not simply use a <dialog> element for dialogs. For it to be a modal dialog, it must be opened using the `.showModal()` method or the invoker command `command="show-modal"`.
The hack of needing to implement roving tabindex techniques is not due to the failings of accessibility tools but because of web standards have not yet provided an alternative (adding the `focusgroup` attribute to the HTML standard is in the works).
The entire purpose of <b> was what it looked like. They changed its definition to not be about what it looked like but why an author might make it look that way, i.e. to bring attention to it. The representation flows from the motivation, there's no need to embed a look in the definition.
Because the elements already exist. When the elements were invented and defined, CSS didn't exist and authors had to use elements to make presentational changes.
When HTML5 was defined, CSS was well established and it was an opportunity to update element descriptions to get rid of specific presentational qualities.
There are lots of elements, if you don't find some of them useful, don't use them. Other people may find uses for the distinctions; even if they use distinctive styling for them all, they may need to document why they're used, not just for all the authors but for the audience as well; clearly we can't expect developers to know what all the elements are for so that's doubly true for the audience.
In practice today, that's fine. Typically authors have a hard time differentiating what "emphasis," "importance," and "bring attention to" mean to them. Therefore, nothing conveys a distinction by default.
lol, you should actually read the HTML spec, there are good explanations of all the elements. The whole point of defining semantics is that elements have meaning
independent of their default appearance (or any appearance).
> I need to learn more about web accessibility, but if you completely ignore it (and other sane practices) HTML looks really simple.
Everything looks really simple when you ignore vast amounts of the subject and nuance.
Your rules don't mention keyboard or focus behavior, the only mention of either is the association between <label> and its <input>. <output> does have functionality, it's an HTML-native ARIA live region (that can be associated with a <label>).
https://html.spec.whatwg.org/multipage/
Well, it took about a decade for web standards to become a real thing and a lot longer for Web Platform Tests to come to be. Still, while there are lots of tests for DOM construction and visual rendering, testing construction of the accessibility tree is lacking (also keyboard interaction testing).
And that's just for browsers, there's no shared spec for the operating system accessibility APIs the browsers' accessibility tree has to be translated into or how screen readers (and other assistive technologies) will use the OS's APIs.