[HN Gopher] HTML attributes for improved accessibility and user ...
___________________________________________________________________
HTML attributes for improved accessibility and user experience
Author : soheilpro
Score : 161 points
Date : 2023-12-04 10:47 UTC (12 hours ago)
(HTM) web link (www.htmhell.dev)
(TXT) w3m dump (www.htmhell.dev)
| mock-possum wrote:
| > The reversed attribute is used to reverse ordered lists (<ol>)
| in the opposite order.
|
| Holy shit that's been a thing for _ten years_ and I didn't know
| about it??
| chrismorgan wrote:
| Well, IE and EdgeHTML never supported it, so in practice it's
| only been safe to use for twoish years.
|
| (I'd actually completely forgotten it was a recent addition
| rather than from the pre-HTML-5 era.)
| ghusbands wrote:
| > > > The reversed attribute is used to reverse ordered lists
| (<ol>) in the opposite order.
|
| To be clear, it only makes the numbers descending rather than
| ascending. The phrasing above implies it rearranges the list.
| pseudoramble wrote:
| 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.
| liftm wrote:
| 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?)
| CM30 wrote:
| 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.
| chrismorgan wrote:
| The alternative is just specifying the value on each item.
| These two are equivalent: <ol reversed>
| <li>Three <li>Two <li>One </ol>
| <ol> <li value=3>Three <li value=2>Two
| <li value=1>One </ol>
|
| 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.
| lynx23 wrote:
| 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.
| bradygp wrote:
| 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.
| hunter2_ wrote:
| Sounds like the mistake was implementing this exclusively in
| the screen reader instead of as a browser hotkey.
| csswizardry wrote:
| > No mentioning of semantic tags.
|
| Yes, because it's an article about attributes...
| madeofpalk wrote:
| 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?
| orwin wrote:
| It doesn't improve my life, at all.
|
| 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.
| madeofpalk wrote:
| _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?
| tambourine_man wrote:
| 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 right
| now is the one I want to use instead of the first one I
| logged in many days ago.
| stephenr wrote:
| 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.
| tambourine_man wrote:
| Maybe if we ever reach AGI I can ask it kindly to respect
| my checkboxes.
| account42 wrote:
| 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.
| tambourine_man wrote:
| 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
| stephenr wrote:
| > 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.
| dev_slash_null wrote:
| 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.
| stephenr wrote:
| 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.
| dev_slash_null wrote:
| 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.
| stephenr wrote:
| > 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".
| dev_slash_null wrote:
| 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.
| Flimm wrote:
| 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.
| andylynch wrote:
| 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.
| eddd-ddde wrote:
| 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.
| dev_slash_null wrote:
| You can add a "hl=en" parameter to the URL, and most
| Google sites should respect it.
| tambourine_man wrote:
| The "skeleton" of the site usually does, but not the
| content it pulls. Search results and suggestions are
| notorious offenders.
| PrimeMcFly wrote:
| > 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.
| sam_lowry_ wrote:
| What about http://google.com/ncr for No Country Redirect?
| tambourine_man wrote:
| 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.
| stevage wrote:
| 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.
| sylware wrote:
| 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.
|
| https://webaim.org/techniques/tables/
|
| (I am not talking about the abomination of the semantic web from
| a decade ago)
| pphysch wrote:
| Why would you use <table> 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 <style> + appropriate usage of HTML content tags
| is almost certainly going to be less bytes than abusing <table>
| for layout.
| sylware wrote:
| I am a noscript/basic (x)html user, indeed. Not even css.
| samyar wrote:
| It was not what I expected
| anymouse123456 wrote:
| 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 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-...
| 542458 wrote:
| 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.
| SpaceL10n wrote:
| 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".
| bshacklett wrote:
| 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.
| robocat wrote:
| 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.
| duskwuff wrote:
| 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.
| anymouse123456 wrote:
| This. But also for any data for any enumerated type.
|
| It's so effing stupid and short sighted.
| daveoc64 wrote:
| >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.
| tessela wrote:
| re: controls
|
| 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.
| kevincox wrote:
| <link href="https://example.com/de" rel="alternate" hreflang="de"
| />
|
| 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.
| gdcbe wrote:
| > 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
___________________________________________________________________
(page generated 2023-12-04 23:01 UTC)