extra88

Same. Also, proper names should be excluded entirely; the only "Advanced" one I got wrong was a place name.

Their "where is it" data is from https://www.justwatch.com/ maybe that site has its own watchlist feature?

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.

Eh, it's fine, elements should be defined for what they mean, not what they look like. The explanation and distinctions made between <b> and other elements (<i>, <em>, <strong>) make sense.

The suggested (not obligatory) user agent styling for <b> is `font-weight: bolder` an agent or authors could use lots of different things to bring attention to what the element contains and treat it differently from <strong>.

https://html.spec.whatwg.org/multipage/text-level-semantics....

https://html.spec.whatwg.org/multipage/rendering.html#phrasi...

There are already well-defined rules, you just don't like some of the rules, e.g. you can't (today) style <select> options. Keyboard navigation is free as long as you follow the rules about which elements are focusable.

You shouldn't have to care about screen readers the same as you shouldn't have to care which browser someone uses but you always have to care about people; people who can't see or hear what you create, people who can operate a keyboard (or keyboard-equivalent) but not a mouse or touchscreen, people who can use a touchscreen but not a physical keyboard, etc.

Good news! `.ariaNotify()` is basically a real implementation of your hypothetical document.speakText.

https://developer.mozilla.org/en-US/docs/Web/API/Element/ari...

I think popover and invoker commands with polyfills are already the way to go. The polyfills are small (and if you only want to use the "show-modal" invoker, it's like 10 lines to feature detect and polyfills just that).

Many good uses of popover really needs anchor positioning. There's a polyfill for that as well but it's not small.

Note the word "if" at the beginning.

Sure. I don't know where you're claiming that misinformation is coming from, it doesn't have anything to do with what I wrote. I was referring to CSS properties that affect the accessibility tree.

<dialog> is awesome, especially when combined with Invoker commands or `popover`. <menu> does nothing, it's just another name for <ul>.

Because for the user experience, it is identical to <ul>. Use <menu> if it helps you to understand your code but in the browser's accessibility tree and in all other respects, it's just an unordered list.

Conveying that something is a list of actions requires adding ARIA attributes. The article mentions `role=menu` but that's not enough, each item also needs the `menuitem` role. The WAI Authoring Practices Guide explains the roles and interaction expectations; don't copy their coded examples and definitely don't use the roles for navigation menus.

https://www.w3.org/WAI/ARIA/apg/patterns/menubar/

WAI's APG patterns exist to document how ARIA attributes should work, they don't advocate for them to be used in place HTML elements. They also don't test to confirm that they actually work in browsers or with assistive technologies (some specific patterns are fine). For web developers, they're helpful for documenting expected keyboard interaction support and other norms.

Are you still coding to support Internet Explorer? All browsers have supported details/summary since an Edge switched to Chromium in 2020.

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

I'm not familiar with that old tale about Zeldman. It's true that assistive technologies don't know about CSS class names but CSS absolutely can affect a non-sighted screen reader user's experience.

I don't use Tailwind so I don't know if it makes it easier or harder to do the right thing when needing to hide something from everyone or only visually hiding something. Because it's CSS, it can't take care of only hiding something from assistive technologies.

If Tailwind lends itself to using pixels instead of relative units for things that should be relative (like font-size, line-height, etc.), that's a problem. For those users, the HTML elements matter less unless they're savvy users who have custom user stylesheets to selectively adjust the appearance of content instead of changing everything on the page by zooming (e.g. make links, buttons, paragraphs, list items bigger and/or a different font or weight).

That's less accessible and capable than the popover / dialog solution.

BTW, there's a glitch in your code snippet syntax highlighting; in Light mode, the 'p' selector is remaining an unreadable yellow.

That's only a problem with some sans-serif fonts. This very site is using a sans-serif and the capital 'I' has bars in either end so it's not confused with 'l'.

Some sans-serif fonts do add little flourishes to some letters, like 'l', to further distinguish them.