It would have been nice to include a brief explanation of all the ways this feature is likely to break what you expect.
For example, recent versions of Chrome will autocomplete against a table of values across all domains for the given field "name" attribute, regardless of what you put into the autocomplete attribute [0].
I suppose this would be a fine decision if all form fields in all forms represented a global, singular datum (i.e., My Account), but it is not fine at all when dealing with collections of things (i.e., Cars, Parts or whatever).
I managed to recently work around this by generating unique-ish ids for name fields and autocomplete attributes, then fixing them before submission.
I too am incredibly salty from my past accessibility work. Knowing the HTML attributes is one thing, but applying them to your product in a predictable way is another. Folks talk about the importance of cross-browser testing, but willfully neglect cross-screenreader testing. The incentive for industry to meet the needs of these users just isn't where it should be. Too many stakeholders agree that meeting the needs of able users is good enough. Accessibility is just a checkbox for most organizations. A token gesture that "we care" when really it just means "we care enough until we are forced to care more".
YES. I wrote something [0] that combined a whole bunch of annoyances I’ve had at past jobs. Web developers tend to use a private definition of the word “accessible” that’s so hyper technical in specification that any conversation about the actual experience of using assistive technology ends with the something like “why are you using VoiceOver?”. It’s not about the resulting interface, but the specific and lintable stats.
The issue is that 1-2% of users of a random service might use screen readers. As an industry we’ve agreed that it often makes sense to drop support for browsers with more market share. Every screen reader is going to have an order of magnitude smaller user base than the browsers we’ve decided to stop supporting.
“No one” is going to do meaningful cross-reader testing. The only reason “anyone” does any accessibility work at all is the law (and thank god for it).
I really wish this attribute was never added. The idea that a site owner should have that much control over my browser’s behavior is completely contrary to the concept of what a User Agent is intended to be.
I’ve never seen a legitimate use case for disabling autocomplete, but have been prevented from using my password manager on many occasions, resulting in me having to either modify the source code via developer tools, type a very long password, or copy and paste it. Both of the last two cases increase the attack surface for passwords via key logging or clipboard snooping.
The one case that has come close to being legitimate is shared computers, but that should be handled by security controls on the endpoint.
Autofill assumes all fields are associated with the person who is sitting at the computer. That assumption is wrong for an administrator editing user configuration. You don't want the admin's name or address by default if the admin is configuring a new user. Or if the admin role is editing blank user data. Admins are often managers so you can't just disable autocomplete at the browser level.
It's even worse for password fields. Browsers will aggressively attempt to fill the user's password into any password input, regardless of whether it's part of the site's login form or not. This works for most web sites, most of the time -- but it fails horribly for sites where the user really does need to enter a password for something else, like if you're setting a password on a wireless network or setting credentials on a new user you're creating.
The way autocomplete works in browsers is absolutely infuriating. Because a bunch of misguided orgs went around disabling autocomplete on login fields, now browsers aggressively ignore attempts to disable it and there's no elegant way to turn it off when browsers are wrong i.e., when they're autofilling user login data into database credentials.
IMHO, it's far less bad to have some "misguided orgs" disable a feature on software they wrote than to have misguided browser engineers force all web software to suggest obviously inappropriate nonsense to billions of users, forever.
How does hreflang improve accessibility and user experience?
The article says "You can improve the user experience" with it, but never actually demonstrates that. It then starts talking about some SEO stuff, but it's still not super clear what it actually does?
When I have questions about a concept and I use the english word for it (because I never learned CS in French and would not understand the French page), the first Wikipedia page will still be in French, because of those shitty tags. Honestly, those are only useful if the words are the same in multiple languages.
As for me, this recent changes get on my nerves, and are one reason why I'm not using Google anymore.
Ha, I once had the exact opposite problem. I studied part of my CS degree in France, in French, but for some reason when I went to sit the exam, they thought I would like to have the exam in English. I freaked out - I didn't know any of the terms in English, only in French. Fortunately they had a spare copy in French for me to work from.
Is it because of those tags? Or is it just because Google on its own has done a comprehensive job of indexing and incorrectly thought you wanted the French version?
You don’t even need to travel - I’ve seen Google decide at different times that I should be getting Polish, French, or Portuguese, instead of English from my desktop in London.
Yeah, those were the days, but that doesn't work anymore. I see plenty of Portuguese results in google.com, even though I have only English as “Preferred Language” and “Automatically add languages: Off” in https://myaccount.google.com/language
Same with all the other rants above. Turning off autoplay in Youtube has become a weekly tradition here, like watering the cactus.
Hmm my google chrome seems to correctly handle everything in English. It must be a combination of setting my machine locale to English and probably on my Google account as well, no need for vpns.
I mean look I have to sympathise with Google here. They've no doubt had the entire combined wisdom of Google looking at this problem and clearly there is just no way for human beings to comprehend what the `Accept-Language` header does.
It's absurd how they keep finding new ways to make this worse. They have ignored `Accept-Language: en` for a long time but used to at least have a link to switch to the english version. Then that link stopped appearing on search result pages and now it doesn't even consistently show up on the home page. Now it seems they don't even fully respect the account language wile logged in. WTF.
While on vacation google decided to switch me to chinese even though I was logged in with an account that was set to english for decades on a browser that didn't change. The only way to change that back is to go to your account settings, and all the links leading there are ... in chinese. Even once back home this language change persisted. At no point did Google ever get an `Accept-Language: zh*` from me or any other indication that I wanted to switch languages besides the IP I'm connecting from which means fuck all.
My guess is it's a mixture of malice (I know this person said it doesn't want X, but maybe we can sell them X in this particular situation, so just go for it anyways) and pure simple incompetence and lack of communication in a large enough org
The other day someone here (ostensibly a site for tech people) argued that the `Accept` header is useless, we can all just put random query string parameters or extensions in the URL to tell the server what content type we expect back, so I wouldn't be surprised if Google developers simply fail to see the point of the Accept-Language header.
Except, in non English speaking counties, the vast majority of people do not change the Accept-Language header (through various browser/OS mechanisms), and receive default results. But then experiments show that they are more likely to interact with pages when shown in the languages Google thinks you actually use.
If you go to myaccount.google.com/language , you can remove languages you don't actually speak, or turn off automatically adding languages altogether. It doesn't always work for everything, but it's a good signal.
I agree there should be a way to force this better, but there's a bunch of work being done on it.
You can add a hl=en parameter to the URL, and most Google apps will respect it.
I've heard this excuse before, and I don't buy it.
I live in a non-English speaking country.
The vast majority of people use their device in the local language, and for any browser to see the OS is set to - let's say, Thai - and then just proceed to send accept-language: en is just absurd.
The other possibility is that these people who can not understand English, somehow manage to use a device set to English language on a daily basis. Also, absurd.
Unfortunately, thats just not true. Accept-Lanuage is set to English most of the time, even for people in non-enlish speaking counties. It's not that they cannot use English, it's that experiments show that users are more likely to interact with content that is in their predicted language, even when Accept-Language is set to English.
> Accept-Lanuage is set to English most of the time, even for people in non-enlish speaking counties.
Unless you can point to some kind of evidence that shows Accept-Language is set to English regardless of the host OS' language/region setting, there's zero reason to believe this claim.
> It's not that they cannot use English
Right, the entirety of non-english speaking, internet-using humans are able to read English, it's just a bunch of them choose not to, but only when it comes to using a webpage? Is that what you're suggesting?
Edit:
I just did some very quick testing of the theory that browsers will send the "wrong" Accept-Language header.
* Safari on macOS with preferred OS language set to English (Australian) sends `en-AU,en;q=0.9`
* Safari on macOS with preferred OS language set to Thai (and second pref of English) sends `th-TH,th;q=0.9`
* Chrome on macOS with preferred OS language set to English (Australian) for some reason sends `en-GB,en-US;q=0.9,en;q=0.8`
* Chrome on macOS with preferred OS language set to Thai (and second pref of English) sends `th-TH,th;q=0.9`
* Edge on Windows 11 with preferred OS language set to Thai (and second pref of English) sends `th,en;q=0.9,en-GB;q=0.8,en-US;q=0.7`
* Chrome on Windows 11 with preferred OS language set to Thai (and second pref of English) sends `th-TH,th;q=0.9`
Firefox is the one that can get it wrong, sometimes: in the macOS VM, I had already downloaded Firefox before setting the OS language to Thai, and the downloaded versions set a browser preferred language which doesn't change based on the OS language (the default is US English).
But when I downloaded Firefox using Edge in the Win11 VM, the language was already set to Thai, so I got a "Thai preferred" download link when I typed "Firefox" in the search bar, and thus the language string it sends is not surprising: `th,en-US;q=0.7,en;q=0.3`
So, again: without some evidence to show that somehow people who have no understanding of English, are using their computers or phones or tablets in English, I'm calling bullshit on this repeated claim that "non english user's browsers send requests for English language content".
In many counties, users have their OS/Browser settings set to English only, when they actually also speak other languages (or in certain countries, exclusively other languages). There's also a bunch of complexity in regards to spoken/written language comprehension, but I won't get into that here.
There is much more engagement when Google presents content in languages people actually know (or, rather, languages Google thinks they know), regardless of what their Accept-Language header is.
Unfortunately, I cannot present you with hard stats, as I no longer work there. I'm sorry that's unsatisfactory, and I'm not asking you to blindly trust the word of a stranger. Just wanted to offer up some insight into why the system behaves as it does sometimes.
I've seen quite a few people with my own eyes use devices with an English interface (or French) without knowing much English (or French). Some of them are illiterate. This is quite common in some parts of the world. These people find use in their English devices, because websites like YouTube provide content in their language even when the interface is not in their language.
Sometimes these people cannot switch the interface language of the operating system. For example٫ Windows Single Language edition forbids changing the language of the interface, and it is common in developing countries.
That is a really cool idea, but does any browser actually do anything with this info? Maybe search engines do but it would be really cool if the browser could pop up something like "This page is also available in German, [Visit]" to help the user. Finding the "English" link, which may be spelt in the page language, or be a US or UK flag is not a fun task when I stumble across a page of the wrong language.
No mentioning of semantic tags. I personally think things like <main> and <article> are way more practically usful for accessibility these days. Many screen readers have a "jump to main" shortcut these days (which is a great replacement for those notorious "skip to content" links). If only more sites would use these tags.
I don’t think jump to main can replace a skip to content link because screen readers aren’t often used by people who are sighted but aren’t able to use a mouse. Skip nav still helps them bypass the repetitive heading content.
And html table layout are not harmful, actually 2D semantic HTML documents can do wonders as they can be reasonably displayed with a hardcoded css beyond good enough.
The only thing missing is how to display the table rules, but from a semantic point of view. Namely, I would kind of un-obsolete the table BORDER attribute, as it gives the information that seeing the rules is somewhat important. Or maybe an attribute being more explicit than it is a semantic value, meaning rules are sufficiently important, for instance a rule level, that a css or a hardcoded css (could still be dynamically configured) would choose to display or not. For instance, like a WEIGHT attribute with NORMAL(default) and STRONG value, or directly a STRONG attribute, even though un-obsoleting BORDER changing the definition of its value being a scale of it strenght (0, rules would not be displayed, not 0 rules would displayed in hardcoded css) would fairly enough.
Yeah the behavior was completely counter intuitive to what I was expecting. It does make sense though since it would be kinda weird if an HTML attribute could change the structure of mark up directly, at least I realized that after thinking about it.
How does this help accessibility, though?
(Maybe I don't know enough about HTML. Is the usual way to produce a descending enumeration to write the elements in reverse order and then re-reverse them in CSS or so, which makes them be read wrong by screen readers?)
Note also that reversing content via CSS is generally unwise, because things like screen readers, text selection and tab indexing operate on DOM tree order.
That's a good point. There's no obvious way to mark up a HTML list as being reversed in CSS alone, at least not without a bunch of Flexbox styles and stuff. So the likelihood that someone would use an unsemantic alternative for this is basically non existent.
Custom controls are the enshittification of the <video> tag. IMHO there's no custom video component that allows the user to control volume, picture-in-picture, AirPlay, control speed and scrubbing better than the standard controls, especially on mobile.
I’m not a web dev so I might be missing something obvious… but…
Why the obsession with binding languages to a url (resource)?
There’s an accept-language http header that will respect the user’s languages in desired order… I can understand you as a user might want to be able to overwrite it for a specific site so that they can workaround a badly translated site, but even for that purpose you can use a simple opt-in cookie…
But why attach it to a resource (url)??? Now when I share the url it will not respect the language preferences of the one I share it too…
And even if you wish to be able to share a specific language version of a website, why not have these as an extra layer that redirect with a cookie setting that language and then just use again the regular url…
Honestly this boggles my mind… why why… can web developers and their managers please respect http standards… with the german trial case we might see some traction with DNT, so there’s that. Please also respect my language setting.
Fun (read supper annoying) fact: ever worse is trying to use ip to map it to location and then deduce language like that… I live in Belgium and how many times I’ve received a French version of a site is mind boggling… sorry very sorry, but I’m not fluent in French. I can survive in it, but I don’t want to consume websites in it if I don’t have to.. if you actually would respect my browser settings (accept-language) you would know better… zzz
It would have been nice to include a brief explanation of all the ways this feature is likely to break what you expect.
For example, recent versions of Chrome will autocomplete against a table of values across all domains for the given field "name" attribute, regardless of what you put into the autocomplete attribute [0].
I suppose this would be a fine decision if all form fields in all forms represented a global, singular datum (i.e., My Account), but it is not fine at all when dealing with collections of things (i.e., Cars, Parts or whatever).
I managed to recently work around this by generating unique-ish ids for name fields and autocomplete attributes, then fixing them before submission.
I'm obviously still salty.
[0] https://stackoverflow.com/questions/12374442/chrome-ignores-...