12 ms·

This is a fantastic article, it does miss one very key point about bog-standard HTML which is worth mentioning though. The standard widgets are all accessible,

This is a fantastic article, it does miss one very key point about bog-standard HTML which is worth mentioning though. The standard widgets are all accessible, people with screen readers, limited mobility, poor vision, etc, all rely on pages being written so the devices they use to read the web can function properly. People who choose to eschew these standard components very frequently end up with a site which is unusable for disabled people. Very few people have the skill to turn a div into an effective button, yet over and over I see web sites with rows of buttons which are in fact just divs with javascript behind them. Making your site accessible isn't just a good practice, in the US, it is the law. Courts have ruled that the ADA applies to web sites along with any other type of business. A small sample of sites where people thought they could smash together super-fancy sites without concern for basic needs of users: https://www.atilus.com/top-10-ada-lawsuits/ https://www.atilus.com/top-10-ada-lawsuits/

arcturus17 6y ago
> Making your site accessible isn't just a good practice, in the US, it is the law > Courts have rules that the ADA applies to web sites along with any other type of business For a business like a coffee shop I'd imagine that accessibility is codified in law through things like building regulations (ie, you must have n disabled parking spots per square foot, a disabled toilet, etc) Is there an equivalent legally codified and enforceable standard for the web?
- rstupek 6y ago
  There is not a codified standard however that doesn't stop websites from being sued
  - ogre_codes 6y ago
    If you comply with the WCAG 2.1, you have a pretty good legal defense. While it isn't "Law", it is the most widely known published standard and likely to be added to the law soon. https://www.w3.org/TR/WCAG21/ https://www.w3.org/TR/WCAG21/
- udia 6y ago
  I have had a lot of success with this course (Web Accessibility, by Google): https://www.udacity.com/course/web-accessibility--ud891 https://www.udacity.com/course/web-accessibility--ud891 > In this course you’ll get hands-on experience making web applications accessible. You’ll understand when and why users need accessibility. Then you’ll dive into the "how": making a page work properly with screen readers, and managing input focus (e.g. the highlight you see when tabbing through a form.) You’ll understand what "semantics" and "semantic markup" mean for web pages and add ARIA markup to enable navigating the interface with a range of assistive devices. Finally, you’ll learn styling techniques that help users with partial vision navigate your pages easily and reliably.
- ogre_codes 6y ago
  > Is there an equivalent legally codified and enforceable standard for the web? More or less yes. The link I posted has a few good resources, but generally speaking sites need to work with a screen reader and they need to be accessible via the keyboard (which by extension enables other accessibility devices). This site has some more guidelines. https://www.essentialaccessibility.com/blog/ada-guidelines https://www.essentialaccessibility.com/blog/ada-guidelines Generally speaking, if you start with existing components that do the thing you want done, you have a huge leg up. If you try to reinvent the wheel, you are likely in for a lot of trouble. The more complex the control, the harder it is to roll your own. Calendar controls and Selects are particularly tough to get right. UPDATE: Also, the wc3 has some good guidelines which should cover your ass. https://www.w3.org/TR/WCAG21/ https://www.w3.org/TR/WCAG21/
- deleted 6y ago
  [deleted]
elliekelly 6y ago
> Very few people have the skill to turn a div into an effective button, yet over and over I see web sites with rows of buttons which are in fact just divs with javascript behind them. What was the catalyst behind this trend? I just don’t understand the reason behind it. Hasn’t <button> been around forever? Was there some limitation on the button tag that made the div tag more desirable?
- recursive 6y ago
  My guess is that some learn react et al without ever really learning HTML first.
  - pferde 6y ago
    That's entirely possible. I've seen a React tutorial that shows a simple example HTML snippet, and comments on it with "We’ll get to the funny XML-like tags soon."
    - recursive 6y ago
      And then there's jsx, which is different from html in some important ways, and generally a little closer to xml.
- ogre_codes 6y ago
  I suspect a lot has to do with the fact that it's easier to slap together a quick list/ menu thing than it is to make a select box look the way a designer wants it to. Similarly with calendar components, radio buttons, etc.
  - K0nserv 6y ago
    What has happened in that scenario is that the designer has failed in their job. Unfortunately it’s up to engineers to catch this, which they often don’t
    - 6y ago
recursive 6y ago
> Making your site accessible isn't just a good practice, in the US, it is the law. Courts have rules that the ADA applies to web sites along with any other type of business. This seems to imply that web sites are businesses. If my hobby sites are subject to this, I'm going to be in trouble.
- ogre_codes 6y ago
  One of the big linked sites was Beyonce's web site. How big an issue this is depends largely on how big your hobby site is. Update: I think this might even be wrong, its likely personal sites are fine. It's still good practice though!
  - recursive 6y ago
    The size of any of my sites is well below 1 milli-Beyonce.
  - bachmeier 6y ago
    Unless there's a law I haven't heard of (definitely a possibility) it would be necessary to classify it as a commerce site for the law to apply.
    - jcranmer 6y ago
      Taking a quick look at the site, Beyoncé has a store page on it, which would be sufficient to classify it.
      - ogre_codes 6y ago
        With regards to the ADA, commerce means more than just "Selling stuff" so I'd be careful making assumptions about that.
        deleted 6y ago
        [deleted]
pbronez 6y ago
Are there any automated ways to assess a web product against the Web Content Accessibility Guidelines (WCAG)? This should really be part of the CI/CD process.
- ratww 6y ago
  There's a Firefox/Chrome extension called Axe that's pretty good. We use at my company it to make our products accessible and it helped us tremendously. [1] https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/ https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/ [2] https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd https://chrome.google.com/webstore/detail/axe-web-accessibil...
  - bramd 6y ago
    The engine behind that add-on, Axe core, can be called from JS and there are some open source tools around to integrate it in your CI. I would say Axe is kind of the gold standard at this time when it comes to automated accessibility testing. Not because it catches the highest number of issues, but if it flags something you can be pretty sure it's a real issue and not a false positive.
- tingletech 6y ago
  our web team wanted this in the CI/CD https://allyjs.io https://allyjs.io edit: actually it's spelled https://pa11y.org https://pa11y.org
- cptskippy 6y ago
  Yes, there are a lot of tools. None are great and are mostly for compliance. Products like Siteimprove are targeted at Enterprise (e.g. demos with sales weasels, unpublished pricing, etc). They mostly suck but check an auditing and compliance box.
- ahuth 6y ago
  Shameless plug: at work we created axe-storybook-testing [1], which can be used to run accessibility tests against Storybook stories [2] on CI. 1. https://github.com/chanzuckerberg/axe-storybook-testing https://github.com/chanzuckerberg/axe-storybook-testing 2. https://storybook.js.org/docs/react/get-started/whats-a-story https://storybook.js.org/docs/react/get-started/whats-a-stor...
hanniabu 6y ago
Would be nice to have an html builder that follows all these best practices. That would also make it nice and easy to apply different crowdsourced themes.
reificator 6y ago
While I agree with your message of "make things accessible" I think you're pointing the finger the wrong way. > This is a fantastic article, it does miss one very key point about bog-standard HTML which is worth mentioning though. > The standard widgets are all accessible, people with screen readers, limited mobility, poor vision, etc, all rely on pages being written so the devices they use to read the web can function properly. People who choose to eschew these standard components very frequently end up with a site which is unusable for disabled people. > Very few people have the skill to turn a div into an effective button, yet over and over I see web sites with rows of buttons which are in fact just divs with javascript behind them. Using a div as a button is not "bog-standard" HTML or a "standard component". Use a button and be done with it. Using React or whatever does not prevent you from doing this, and in fact makes it less obvious to anyone doing a cursory review. I've not seen any difference overall in the amount of people knowingly using divs as buttons with plain HTML vs whatever framework, but I have seen an increase in unknowingly doing so by importing a calendar widget or similar without reviewing it.
- ogre_codes 6y ago
  > Using a div as a button is not "bog-standard" HTML or a "standard component". Use a button and be done with it. Fully agree. In fact that is exactly point I was trying to make.
- madeofpalk 6y ago
  FWIW, using React or whatever makes it more obvious that you're making these mistakes because your event handlers are attached right on the "HTML" element. It makes it easy to spot because you see <div className="button" onClick={handler}> and it immedaitely sticks out as a mistake. Because its easier to statically understand these mistakes, theres even tooling to automate detecting some of them as you type https://www.npmjs.com/package/eslint-plugin-jsx-a11y https://www.npmjs.com/package/eslint-plugin-jsx-a11y
  - reificator 6y ago
    > FWIW, using React or whatever makes it more obvious that you're making these mistakes because your event handlers are attached right on the "HTML" element. It makes it easy to spot because you see > <div className="button" onClick={handler}> > and it immedaitely sticks out as a mistake. Because its easier to statically understand these mistakes, theres even tooling to automate detecting some of them as you type https://www.npmjs.com/package/eslint-plugin-jsx-a11y https://www.npmjs.com/package/eslint-plugin-jsx-a11y I'm not sure how you got that out of > I have seen an increase in unknowingly doing so by importing a calendar widget or similar without reviewing it. I'm referring to: <div class="div-button" onclick="clickHandler()" /> VS: <SomeGreatNpmWidget onClick={clickHandler} /> The point of using components is so that you don't have to look under the covers to understand them at a high level, but that also means if you don't look you don't see how they're breaking accessibility.
codazoda 6y ago
> Very few people have the skill to turn a div into an effective button, yet over and over I see web sites with rows of buttons which are in fact just divs with javascript behind them. I created a minimalist CSS framework called Neat CSS (https://neat.joeldare.com https://neat.joeldare.com). I use anchors instead of buttons and explain why in the quote below. I'd love feedback on the accessibility of that alternative. It's best to use semantic web tags whenever possible. Buttons are a unique case where you're typically linking somewhere, but the button tag doesn't currently support the href attribute. So, buttons are anchor tags with a class of button.
- wizzwizz4 6y ago
  Conceptually, those are links, not buttons. Buttons are for forms and JavaScript and such.
  - codazoda 6y ago
    Fair. I would typically us a form tag with an input tag inside it for forms. Sounds like the button tag can be styled a little more because it allows i, em, br, img, and similar tags inside it, while an input does not. They are interchangable in the case of a form (based on your style need).
    - petepete 6y ago
      There are more ways to interact with a link than a button. You can drag it to your tab bar, bookmarks or desktop, middle click to open in a new tab, copy the target URL etc. With a button you can push it.
- ogre_codes 6y ago
  FWIW, I'm not an expert on this so take what I say with a grain of salt. An anchor tag that links to another page but looks like a button is probably fine. So long as you can access them via the keyboard (tabbing to it) and they have a distinct appearance when focused so if you are tabbing through you can see whats active (this is different from the hover attribute).
lastofthemojito 6y ago
One of the great things about accessibility is that it often doesn't just benefit people with disabilities. My wife and I have watched a lot of TV in the past year with the volume down and captioning on, while we enjoy some down time while our baby is sleeping. A ramped entrance to a building allows wheelchair-bound folks access, but it also helps able-bodied people using delivery dollies. Making simple, lightweight web pages makes them accessible to those with older browsers and devices, but it also saves power consumption, time, and frustration for folks on M1 MacBook Pros.
- dmhmr 6y ago
  I might be misinterpreting your last sentence regarding M1 MacBook Pros. Are you saying they are underpowered for surfing the internet?
  - lastofthemojito 6y ago
    The M1 MacBook Pro is at the other end of the spectrum from the outdated/underpowered device that requires a lightweight web page. But the user of such a fast machine still benefits from lightweight web pages (faster loading times, less CPU usage, etc).
  - jaywalk 6y ago
    What he's saying is that this stuff has benefits even for people using modern, powerful machines like the M1 MacBook Pro.
  - deleted 6y ago
    [deleted]
- ogre_codes 6y ago
  Yes, absolutely. I use closed caption when possible because often I don't quite hear things right and can't make out words. I could turn up the TV, but this means I can enjoy it at the same volume as everyone.
  - zzo38computer 6y ago
benbristow 6y ago
> Very few people have the skill to turn a div into an effective button, yet over and over I see web sites with rows of buttons which are in fact just divs with javascript behind them. You can add role="button" and a modern browser will treat it just like a normal button and all the accessibility that comes with it.
- GrumpyNl 6y ago
  its about simple html and older devices, so just plain button will do the job.
- darekkay 6y ago
  I wish this would be the case. The button will not be focusable, so we need to add tabindex="0". A disabled div with role="button" is not handled as disabled, so we need to take care of that. Keyboard space/enter will not be triggered on "click" event, unlike real buttons, hence excluding keyboard users. You can check my playground [1] - I'm using it to demo why one should prefer native over custom components. [1] https://darekkay.github.io/presentations/accessible-web/resources/custom-component.html https://darekkay.github.io/presentations/accessible-web/reso...
- vxNsr 6y ago
  That's kind of missing the point though, most bad browsers the author mentions don't do modern web very well. They're likely using an older renderer and are missing many features.
908B64B197 6y ago
That was the original idea behind HTML. It might not get rendered the same everywhere depending on the device receiving it. If the goal was to send pixel perfect pages, the web would have settled on postscript + hyperlinks.
pier25 6y ago
It would be great if browsers implemented other common elements such as sortable data tables, carousels, etc. https://open-ui.org/ https://open-ui.org/
- gcblkjaidfj 6y ago
  You have a great point. Browser UI elements are stuck in time and all the attention now is directed to things that Google can make money from (e.g. DRM, sandbox for rich apps/extensions, webrtc for their video call products, etc) but your cited site is not a good advocacy of that. Not even the most exalted UI framework fix the most obvious problems with those either. e.g. tables still won't hold the header and first column(s) while scrolling. Most of the these elements does not help consuming information, like carousels. And any true UX designer abhor them all for the fallacy they are.
  - kuschku 6y ago
    > e.g. tables still won't hold the header and first column(s) while scrolling. https://caniuse.com/css-sticky https://caniuse.com/css-sticky position:sticky works on tables.
    - gcblkjaidfj 6y ago
      It's all red :( No support anywhere but Firefox. In fact, I will now use this URL as my main argument in support of firefox! even the grand-parent, javascript infused solutions, only two out of 20 support this extremely basic and obvious use case. Web UI standards are a joke. Everyone involved only cares about rich ads and accordions/carrousels which are lame ways to shove lots of content in a badly designed space.
      - kuschku 6y ago
        Why? The yellow/striped fields mean it's still supported (as long as you add it to th instead of thead/tr):
- 6y ago
analog31 6y ago
I remember learning about HTML for the first time, maybe in Byte Magazine. It was before I actually had a computer with a browser. But the article talked about a benefit of HTML, which was that the tags could be interpreted by custom browsers for accessibility, including for the blind or sight-impaired. It seemed like a pretty cool idea to me. Later on, when people started treating web design as a general purpose graphical and GUI framework, many of the accessibility benefits probably vanished.
- DCoder 6y ago
  Yeah, nowadays most of the sites are suffering from div-ititis that has no semantics, massive blackholes of JavaScript that have to be loaded and processed before you can even see plain text, and CSS class names that are randomly hashed with each deployment in the name of modularity. General accessibility be damned. <noscript> fallback messages be damned. (Except when snitching on your page views to Google Analytics, that's too important to be neglected! I wonder if GA has any default marker to let their customers distinguish these views from normal ones, or if that's still left to each customer to implement manually.) UI customizations in the form of browser extensions and styles be damned. Ad blocking be damned.
trissylegs 6y ago
> Very few people have the skill to turn a div into an effective button, yet over and over I see web sites with rows of buttons which are in fact just divs with javascript behind them. Gahhh. I use either an <a> or a <button> and put style on it. Has all the same visual appeal of the equivalent div. But it already is a button.
- DCoder 6y ago
  > use either an <a> or a <button> Generally, it should be noted that an <a> tag is only appropriate if it makes sense to right-click this element and get options to "open in new tab" or "add to bookmarks". All the stupid "buttons" implemented as <a href="#"> + e.preventDefault() need to die.
  - trissylegs 6y ago
    Yea I use <a> if it's a navigation button for react-router. But it still shows up like a URL because we're using the Browser history (it just updates the URL and renders the new page, each route has a URL and resource id's are in the url). As opening the URL directly should work (if authenticated) it makes sense to use <a> tags.
rkangel 6y ago
Designing for people with disabilities usually increases the overall UX for everyone. I see it a bit like resistance training for fitness - you train in a 'more difficult than normal' scenario, and then when you return to normal it feels much easier.

arcturus17 6y ago

> Making your site accessible isn't just a good practice, in the US, it is the law > Courts have rules that the ADA applies to web sites along with any other type of business For a business like a coffee shop I'd imagine that accessibility is codified in law through things like building regulations (ie, you must have n disabled parking spots per square foot, a disabled toilet, etc) Is there an equivalent legally codified and enforceable standard for the web?

rstupek 6y ago
There is not a codified standard however that doesn't stop websites from being sued
- ogre_codes 6y ago
  If you comply with the WCAG 2.1, you have a pretty good legal defense. While it isn't "Law", it is the most widely known published standard and likely to be added to the law soon. https://www.w3.org/TR/WCAG21/ https://www.w3.org/TR/WCAG21/
udia 6y ago
I have had a lot of success with this course (Web Accessibility, by Google): https://www.udacity.com/course/web-accessibility--ud891 https://www.udacity.com/course/web-accessibility--ud891 > In this course you’ll get hands-on experience making web applications accessible. You’ll understand when and why users need accessibility. Then you’ll dive into the "how": making a page work properly with screen readers, and managing input focus (e.g. the highlight you see when tabbing through a form.) You’ll understand what "semantics" and "semantic markup" mean for web pages and add ARIA markup to enable navigating the interface with a range of assistive devices. Finally, you’ll learn styling techniques that help users with partial vision navigate your pages easily and reliably.
ogre_codes 6y ago
> Is there an equivalent legally codified and enforceable standard for the web? More or less yes. The link I posted has a few good resources, but generally speaking sites need to work with a screen reader and they need to be accessible via the keyboard (which by extension enables other accessibility devices). This site has some more guidelines. https://www.essentialaccessibility.com/blog/ada-guidelines https://www.essentialaccessibility.com/blog/ada-guidelines Generally speaking, if you start with existing components that do the thing you want done, you have a huge leg up. If you try to reinvent the wheel, you are likely in for a lot of trouble. The more complex the control, the harder it is to roll your own. Calendar controls and Selects are particularly tough to get right. UPDATE: Also, the wc3 has some good guidelines which should cover your ass. https://www.w3.org/TR/WCAG21/ https://www.w3.org/TR/WCAG21/
deleted 6y ago
[deleted]

elliekelly 6y ago

> Very few people have the skill to turn a div into an effective button, yet over and over I see web sites with rows of buttons which are in fact just divs with javascript behind them. What was the catalyst behind this trend? I just don’t understand the reason behind it. Hasn’t <button> been around forever? Was there some limitation on the button tag that made the div tag more desirable?

recursive 6y ago
My guess is that some learn react et al without ever really learning HTML first.
- pferde 6y ago
  That's entirely possible. I've seen a React tutorial that shows a simple example HTML snippet, and comments on it with "We’ll get to the funny XML-like tags soon."
  - recursive 6y ago
    And then there's jsx, which is different from html in some important ways, and generally a little closer to xml.
ogre_codes 6y ago
I suspect a lot has to do with the fact that it's easier to slap together a quick list/ menu thing than it is to make a select box look the way a designer wants it to. Similarly with calendar components, radio buttons, etc.
- K0nserv 6y ago
  What has happened in that scenario is that the designer has failed in their job. Unfortunately it’s up to engineers to catch this, which they often don’t
  - 6y ago

recursive 6y ago

> Making your site accessible isn't just a good practice, in the US, it is the law. Courts have rules that the ADA applies to web sites along with any other type of business. This seems to imply that web sites are businesses. If my hobby sites are subject to this, I'm going to be in trouble.

ogre_codes 6y ago
One of the big linked sites was Beyonce's web site. How big an issue this is depends largely on how big your hobby site is. Update: I think this might even be wrong, its likely personal sites are fine. It's still good practice though!
- recursive 6y ago
  The size of any of my sites is well below 1 milli-Beyonce.
- bachmeier 6y ago
  Unless there's a law I haven't heard of (definitely a possibility) it would be necessary to classify it as a commerce site for the law to apply.
  - jcranmer 6y ago
    Taking a quick look at the site, Beyoncé has a store page on it, which would be sufficient to classify it.
    - ogre_codes 6y ago
      With regards to the ADA, commerce means more than just "Selling stuff" so I'd be careful making assumptions about that.
      - deleted 6y ago
        [deleted]

pbronez 6y ago

Are there any automated ways to assess a web product against the Web Content Accessibility Guidelines (WCAG)? This should really be part of the CI/CD process.

ratww 6y ago
There's a Firefox/Chrome extension called Axe that's pretty good. We use at my company it to make our products accessible and it helped us tremendously. [1] https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/ https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/ [2] https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd https://chrome.google.com/webstore/detail/axe-web-accessibil...
- bramd 6y ago
  The engine behind that add-on, Axe core, can be called from JS and there are some open source tools around to integrate it in your CI. I would say Axe is kind of the gold standard at this time when it comes to automated accessibility testing. Not because it catches the highest number of issues, but if it flags something you can be pretty sure it's a real issue and not a false positive.
tingletech 6y ago
our web team wanted this in the CI/CD https://allyjs.io https://allyjs.io edit: actually it's spelled https://pa11y.org https://pa11y.org
cptskippy 6y ago
Yes, there are a lot of tools. None are great and are mostly for compliance. Products like Siteimprove are targeted at Enterprise (e.g. demos with sales weasels, unpublished pricing, etc). They mostly suck but check an auditing and compliance box.
ahuth 6y ago
Shameless plug: at work we created axe-storybook-testing [1], which can be used to run accessibility tests against Storybook stories [2] on CI. 1. https://github.com/chanzuckerberg/axe-storybook-testing https://github.com/chanzuckerberg/axe-storybook-testing 2. https://storybook.js.org/docs/react/get-started/whats-a-story https://storybook.js.org/docs/react/get-started/whats-a-stor...

hanniabu 6y ago

Would be nice to have an html builder that follows all these best practices. That would also make it nice and easy to apply different crowdsourced themes.

reificator 6y ago

While I agree with your message of "make things accessible" I think you're pointing the finger the wrong way. > This is a fantastic article, it does miss one very key point about bog-standard HTML which is worth mentioning though. > The standard widgets are all accessible, people with screen readers, limited mobility, poor vision, etc, all rely on pages being written so the devices they use to read the web can function properly. People who choose to eschew these standard components very frequently end up with a site which is unusable for disabled people. > Very few people have the skill to turn a div into an effective button, yet over and over I see web sites with rows of buttons which are in fact just divs with javascript behind them. Using a div as a button is not "bog-standard" HTML or a "standard component". Use a button and be done with it. Using React or whatever does not prevent you from doing this, and in fact makes it less obvious to anyone doing a cursory review. I've not seen any difference overall in the amount of people knowingly using divs as buttons with plain HTML vs whatever framework, but I have seen an increase in unknowingly doing so by importing a calendar widget or similar without reviewing it.

ogre_codes 6y ago
> Using a div as a button is not "bog-standard" HTML or a "standard component". Use a button and be done with it. Fully agree. In fact that is exactly point I was trying to make.
madeofpalk 6y ago
FWIW, using React or whatever makes it more obvious that you're making these mistakes because your event handlers are attached right on the "HTML" element. It makes it easy to spot because you see <div className="button" onClick={handler}> and it immedaitely sticks out as a mistake. Because its easier to statically understand these mistakes, theres even tooling to automate detecting some of them as you type https://www.npmjs.com/package/eslint-plugin-jsx-a11y https://www.npmjs.com/package/eslint-plugin-jsx-a11y
- reificator 6y ago
  > FWIW, using React or whatever makes it more obvious that you're making these mistakes because your event handlers are attached right on the "HTML" element. It makes it easy to spot because you see > <div className="button" onClick={handler}> > and it immedaitely sticks out as a mistake. Because its easier to statically understand these mistakes, theres even tooling to automate detecting some of them as you type https://www.npmjs.com/package/eslint-plugin-jsx-a11y https://www.npmjs.com/package/eslint-plugin-jsx-a11y I'm not sure how you got that out of > I have seen an increase in unknowingly doing so by importing a calendar widget or similar without reviewing it. I'm referring to: <div class="div-button" onclick="clickHandler()" /> VS: <SomeGreatNpmWidget onClick={clickHandler} /> The point of using components is so that you don't have to look under the covers to understand them at a high level, but that also means if you don't look you don't see how they're breaking accessibility.

codazoda 6y ago

> Very few people have the skill to turn a div into an effective button, yet over and over I see web sites with rows of buttons which are in fact just divs with javascript behind them. I created a minimalist CSS framework called Neat CSS (https://neat.joeldare.com https://neat.joeldare.com). I use anchors instead of buttons and explain why in the quote below. I'd love feedback on the accessibility of that alternative. It's best to use semantic web tags whenever possible. Buttons are a unique case where you're typically linking somewhere, but the button tag doesn't currently support the href attribute. So, buttons are anchor tags with a class of button.

wizzwizz4 6y ago
Conceptually, those are links, not buttons. Buttons are for forms and JavaScript and such.
- codazoda 6y ago
  Fair. I would typically us a form tag with an input tag inside it for forms. Sounds like the button tag can be styled a little more because it allows i, em, br, img, and similar tags inside it, while an input does not. They are interchangable in the case of a form (based on your style need).
  - petepete 6y ago
    There are more ways to interact with a link than a button. You can drag it to your tab bar, bookmarks or desktop, middle click to open in a new tab, copy the target URL etc. With a button you can push it.
ogre_codes 6y ago
FWIW, I'm not an expert on this so take what I say with a grain of salt. An anchor tag that links to another page but looks like a button is probably fine. So long as you can access them via the keyboard (tabbing to it) and they have a distinct appearance when focused so if you are tabbing through you can see whats active (this is different from the hover attribute).

lastofthemojito 6y ago

One of the great things about accessibility is that it often doesn't just benefit people with disabilities. My wife and I have watched a lot of TV in the past year with the volume down and captioning on, while we enjoy some down time while our baby is sleeping. A ramped entrance to a building allows wheelchair-bound folks access, but it also helps able-bodied people using delivery dollies. Making simple, lightweight web pages makes them accessible to those with older browsers and devices, but it also saves power consumption, time, and frustration for folks on M1 MacBook Pros.

dmhmr 6y ago
I might be misinterpreting your last sentence regarding M1 MacBook Pros. Are you saying they are underpowered for surfing the internet?
- lastofthemojito 6y ago
  The M1 MacBook Pro is at the other end of the spectrum from the outdated/underpowered device that requires a lightweight web page. But the user of such a fast machine still benefits from lightweight web pages (faster loading times, less CPU usage, etc).
- jaywalk 6y ago
  What he's saying is that this stuff has benefits even for people using modern, powerful machines like the M1 MacBook Pro.
- deleted 6y ago
  [deleted]
ogre_codes 6y ago
Yes, absolutely. I use closed caption when possible because often I don't quite hear things right and can't make out words. I could turn up the TV, but this means I can enjoy it at the same volume as everyone.
- zzo38computer 6y ago

benbristow 6y ago

> Very few people have the skill to turn a div into an effective button, yet over and over I see web sites with rows of buttons which are in fact just divs with javascript behind them. You can add role="button" and a modern browser will treat it just like a normal button and all the accessibility that comes with it.

GrumpyNl 6y ago
its about simple html and older devices, so just plain button will do the job.
darekkay 6y ago
I wish this would be the case. The button will not be focusable, so we need to add tabindex="0". A disabled div with role="button" is not handled as disabled, so we need to take care of that. Keyboard space/enter will not be triggered on "click" event, unlike real buttons, hence excluding keyboard users. You can check my playground [1] - I'm using it to demo why one should prefer native over custom components. [1] https://darekkay.github.io/presentations/accessible-web/resources/custom-component.html https://darekkay.github.io/presentations/accessible-web/reso...
vxNsr 6y ago
That's kind of missing the point though, most bad browsers the author mentions don't do modern web very well. They're likely using an older renderer and are missing many features.

908B64B197 6y ago

That was the original idea behind HTML. It might not get rendered the same everywhere depending on the device receiving it. If the goal was to send pixel perfect pages, the web would have settled on postscript + hyperlinks.

pier25 6y ago

It would be great if browsers implemented other common elements such as sortable data tables, carousels, etc. https://open-ui.org/ https://open-ui.org/

gcblkjaidfj 6y ago
You have a great point. Browser UI elements are stuck in time and all the attention now is directed to things that Google can make money from (e.g. DRM, sandbox for rich apps/extensions, webrtc for their video call products, etc) but your cited site is not a good advocacy of that. Not even the most exalted UI framework fix the most obvious problems with those either. e.g. tables still won't hold the header and first column(s) while scrolling. Most of the these elements does not help consuming information, like carousels. And any true UX designer abhor them all for the fallacy they are.
- kuschku 6y ago
  > e.g. tables still won't hold the header and first column(s) while scrolling. https://caniuse.com/css-sticky https://caniuse.com/css-sticky position:sticky works on tables.
  - gcblkjaidfj 6y ago
    It's all red :( No support anywhere but Firefox. In fact, I will now use this URL as my main argument in support of firefox! even the grand-parent, javascript infused solutions, only two out of 20 support this extremely basic and obvious use case. Web UI standards are a joke. Everyone involved only cares about rich ads and accordions/carrousels which are lame ways to shove lots of content in a badly designed space.
    - kuschku 6y ago
      Why? The yellow/striped fields mean it's still supported (as long as you add it to th instead of thead/tr):
6y ago

analog31 6y ago

I remember learning about HTML for the first time, maybe in Byte Magazine. It was before I actually had a computer with a browser. But the article talked about a benefit of HTML, which was that the tags could be interpreted by custom browsers for accessibility, including for the blind or sight-impaired. It seemed like a pretty cool idea to me. Later on, when people started treating web design as a general purpose graphical and GUI framework, many of the accessibility benefits probably vanished.

DCoder 6y ago
Yeah, nowadays most of the sites are suffering from div-ititis that has no semantics, massive blackholes of JavaScript that have to be loaded and processed before you can even see plain text, and CSS class names that are randomly hashed with each deployment in the name of modularity. General accessibility be damned. <noscript> fallback messages be damned. (Except when snitching on your page views to Google Analytics, that's too important to be neglected! I wonder if GA has any default marker to let their customers distinguish these views from normal ones, or if that's still left to each customer to implement manually.) UI customizations in the form of browser extensions and styles be damned. Ad blocking be damned.

trissylegs 6y ago

> Very few people have the skill to turn a div into an effective button, yet over and over I see web sites with rows of buttons which are in fact just divs with javascript behind them. Gahhh. I use either an <a> or a <button> and put style on it. Has all the same visual appeal of the equivalent div. But it already is a button.

DCoder 6y ago
> use either an <a> or a <button> Generally, it should be noted that an <a> tag is only appropriate if it makes sense to right-click this element and get options to "open in new tab" or "add to bookmarks". All the stupid "buttons" implemented as <a href="#"> + e.preventDefault() need to die.
- trissylegs 6y ago
  Yea I use <a> if it's a navigation button for react-router. But it still shows up like a URL because we're using the Browser history (it just updates the URL and renders the new page, each route has a URL and resource id's are in the url). As opening the URL directly should work (if authenticated) it makes sense to use <a> tags.

rkangel 6y ago

Designing for people with disabilities usually increases the overall UX for everyone. I see it a bit like resistance training for fitness - you train in a 'more difficult than normal' scenario, and then when you return to normal it feels much easier.