HTML attributes for improved accessibility and user experience • Hacker News Board

Re: HTML attributes for improved accessibility and user experience

#31

Post by stephenr » Mon, Dec 04, 2023, 3:49 PM UTC

dev_slash_null wrote: post #29

stephenr wrote: post #13

Earlier quoted context omitted.

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. /s because, you know.

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…

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.

Re: HTML attributes for improved accessibility and user experience

#32

Post by chrismorgan » Mon, Dec 04, 2023, 4:12 PM UTC

liftm wrote: post #18

mock-possum wrote: post #2

> The reversed attribute is used to reverse ordered lists ( ) in the opposite order. Holy shit that’s been a thing for ten years and I didn’t know 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?)

The alternative is just specifying the value on each item. These two are equivalent:

  
    Three
    Two
    One
  

  
    Three
    Two
    One

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.

Re: HTML attributes for improved accessibility and user experience

#33

Post by csswizardry » Mon, Dec 04, 2023, 4:13 PM UTC

lynx23 wrote: post #3

No 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.

> No mentioning of semantic tags.

Yes, because it’s an article about attributes…

Re: HTML attributes for improved accessibility and user experience

#34

Post by dev_slash_null » Mon, Dec 04, 2023, 4:20 PM UTC

stephenr wrote: post #31

dev_slash_null wrote: post #29

Earlier quoted context omitted.

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…

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…

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.

Re: HTML attributes for improved accessibility and user experience

#35

Post by stephenr » Mon, Dec 04, 2023, 4:31 PM UTC

dev_slash_null wrote: post #34

stephenr wrote: post #31

Earlier quoted context omitted.

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…

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".

Re: HTML attributes for improved accessibility and user experience

#36

Post by tambourine_man » Mon, Dec 04, 2023, 4:37 PM UTC

dev_slash_null wrote: post #28

tambourine_man wrote: post #12

Earlier quoted context omitted.

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…

You can add a "hl=en" parameter to the URL, and most Google sites should respect it.

The “skeleton” of the site usually does, but not the content it pulls. Search results and suggestions are notorious offenders.

Re: HTML attributes for improved accessibility and user experience

#37

Post by PrimeMcFly » Mon, Dec 04, 2023, 4:41 PM UTC

tambourine_man wrote: post #12

madeofpalk wrote: post #10

Earlier 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…

> There's just no way to convince Google to use English-only when I'm in another country other than using a VPN.

There are browser settings you can force or failing that, an extension.

Re: HTML attributes for improved accessibility and user experience

#38

Post by bshacklett » Mon, Dec 04, 2023, 4:55 PM UTC

anymouse123456 wrote: post #19

re: 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 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.

Re: HTML attributes for improved accessibility and user experience

#39

Post by [deleted] » Mon, Dec 04, 2023, 4:58 PM UTC

SpaceL10n wrote: post #26

anymouse123456 wrote: post #19

re: 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 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…

[deleted]

Re: HTML attributes for improved accessibility and user experience

#40

Post by stephenr » Mon, Dec 04, 2023, 5:15 PM UTC

tambourine_man wrote: post #22

account42 wrote: post #16

Earlier quoted context omitted.

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 decid…

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

> pure simple incompetence

Hanlon's razor strikes again.

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.