HTML attributes for improved accessibility and user experience
41–50 of 56 posts
Re: HTML attributes for improved accessibility and user experience
#42No mentioning of semantic tags. I personally think things like and 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.
Sounds like the mistake was implementing this exclusively in the screen reader instead of as a browser hotkey.
Re: HTML attributes for improved accessibility and user experience
#43re: the autocomplete attribute. 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 al…
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 to…
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.
Re: HTML attributes for improved accessibility and user experience
#44Earlier quoted context omitted.
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,…
Let me clarify what I'm claiming here.
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.
Re: HTML attributes for improved accessibility and user experience
#45> Why use hreflang?
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
Re: HTML attributes for improved accessibility and user experience
#46> Why use hreflang? 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 us…
[deleted]
Re: HTML attributes for improved accessibility and user experience
#47Earlier quoted context omitted.
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 to…
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.
Re: HTML attributes for improved accessibility and user experience
#48re: the autocomplete attribute. 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 al…
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 to…
>I’ve never seen a legitimate use case for disabling autocomplete
The main one is going to be any kind of web system where the user is typing in other people's details.
Search fields can also be a bit annoying - I've seen Firefox autocomplete entries in search fields that make no sense.
For example, Firefox suggests my postal code as a search term here on HN.
Re: HTML attributes for improved accessibility and user experience
#49Earlier quoted context omitted.
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?
There's just no way to convince Google to use English-only when I'm in another country other than using a VPN. I changed the settings multiple times, disabled the auto-detect language, but it always leaks in on suggestions or results. Just like there's no way to make Youtube disable autoplay of videos. One week later or so, it reverts back to its default behavior. Or for Google to respect that the account I'm using r…
What about http://google.com/ncr for No Country Redirect?
Re: HTML attributes for improved accessibility and user experience
#50And 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 b…
Why would you use for layout in 2023?
I've heard of no-JS users, but no-CSS users sounds like an April Fools joke.
A few lines of + appropriate usage of HTML content tags is almost certainly going to be less bytes than abusing for layout.