11 ms·

For all those saying that ARIA trumps semantic elements, consider that for basic interactions semantic elements come out of the box keyboard accessible. For ex

For all those saying that ARIA trumps semantic elements, consider that for basic interactions semantic elements come out of the box keyboard accessible. For example, a <button> will have default tabindex=0 and respond to spacebar key presses, but you'd have to add that yourself if you put role=button on a <div>. In short, if there is a semantic element that matches your need, use it.

extra88 5y ago
> In short, if there is a semantic element that matches your need, use it. Yes! This is known as The First Rule of ARIA.
admax88q 5y ago
If the browser would make the semantic elements actually look good out of the box a lot of developers would use them by default.
- shadowofneptune 5y ago
  It would be equal effort to restyle something done with ARIA compared to a semantic element, yes?
  - admax88q 5y ago
    Depends on the element, the select and input elements are notoriously difficult to style, which is why people often remake them with divs and JS. Combo boxes are a fucking nightmare to style, as are checkboxes and radios. Buttons arnt as bad, but you still spend a lot of time fighting against browser defaults which differ across browsers.
- pjc50 5y ago
  Isn't that an extremely moving target? What looks good is very subject to changes of fashion. Your comment below about being difficult to style is more to the point.
- anoncake 5y ago
  Unfortunately, Firefox recently actually stopped making semantic elements look native (=good).
- JoshTriplett 5y ago
  If people could agree on what "look good" means, I don't think it'd be impossible to get the major browsers to update default styles. But every site seems to have a different idea of the look they want. I'd be curious to see a somewhat-objective look at what's actually wrong with default browser styles, separating out well-established usability and design considerations from personal preferences and branding preferences. I wouldn't be at all surprised if there are near-universal things wrong with the default styles, and those might be possible to change if they can be separated out.
  - Swizec 5y ago
    Based on my experience as a web developer working with many designers over some 20 years of design trends, here’s the problem: Default styles aren’t pretty. That’s it. They’re superior in every other way. You always know what to click, you always know what an element will do, how it behaves, the UX is consistent with your OS, etc. Default elements are fantastic.
    - markdown 5y ago
      Not datepickers. The datepicker element is garbage.
      - admax88q 5y ago
        Too true
    - felixfbecker 5y ago
      > the UX is consistent with your OS Buttons in Chrome on macOS look completely different than in native apps. Buttons and context menu in Chrome's native <video> controls look yet again different, following Material Design. From the things one could argue are good about native browser styles "consistency with the OS" is definitely not one of them.
- tanaypingalkar 5y ago
  You can reset your css
  - lolinder 5y ago
    For some elements, yes. Many others have certain attributes that are completely unstylable, a lot of browser-specific attributes and selectors (not just prefixed attributes but also whole pseudoclasses), or both.
- robin_reala 5y ago
  Who cares about looking good, when we’re talking about working good? Of course, it’s worth putting the effort in to both looking good and working good, but if we’re going to pick one, we should go for the second.
  - worik 5y ago
    I think that is a false dichotomy.
  - lmm 5y ago
    If we're a business then looking good and mostly working ok probably sells better than working good and mostly looking ok.
    - brailsafe 5y ago
      I feel like this is only true in cases where either your product is your appearance or it's highly unlikely the thing you're selling can be returned.
- loloquwowndueo 5y ago
  A div looks like nothing by default. It’s probably about the same amount of effort to make a button look good.
austincheney 5y ago
The one exception for me are forms. In that case I would rather use a div or section tag with role=“form”. I have seen less experienced developers do weird things with form tags and submit event and form tags have unique behaviors associated and requirements.
- brailsafe 5y ago
  I've never heard of this. Could you elaborate on why you'd not use an actual form element?
  - austincheney 5y ago
    Forms cannot be nested. That is an html violation. That is because all submit events fire on all nodes contained by a form on submission even if the page does not go anywhere. Forms also require an action attribute that contains a submission address, which requests a new page on submission.
    - Varriount 5y ago
      What circumstances call for nesting form elements,?
      - testudovictoria 5y ago
        If a dev finds a form to be nested, it's usually because something was tacked on as an afterthought. I'm speaking from experience. I had a project that had applications associated with it. Forms are the natural way to express this. There were some disclosures associated with the application, and there was a modal associated with emailing the disclosures. I needed to add some front end validations to this modal. No matter what I tried, I could not get these validations to trigger correctly. I spent an entire work day on trying to get a library to work with this modal. It wouldn't work, because changing the modal's div to a form tag would cause errors or unexpected behavior due to the nested form tags. TL;DR: Nothing requires it. Devs might not understand the implications.
      - 5y ago

extra88 5y ago

> In short, if there is a semantic element that matches your need, use it. Yes! This is known as The First Rule of ARIA.

admax88q 5y ago

If the browser would make the semantic elements actually look good out of the box a lot of developers would use them by default.

shadowofneptune 5y ago
It would be equal effort to restyle something done with ARIA compared to a semantic element, yes?
- admax88q 5y ago
  Depends on the element, the select and input elements are notoriously difficult to style, which is why people often remake them with divs and JS. Combo boxes are a fucking nightmare to style, as are checkboxes and radios. Buttons arnt as bad, but you still spend a lot of time fighting against browser defaults which differ across browsers.
pjc50 5y ago
Isn't that an extremely moving target? What looks good is very subject to changes of fashion. Your comment below about being difficult to style is more to the point.
anoncake 5y ago
Unfortunately, Firefox recently actually stopped making semantic elements look native (=good).
JoshTriplett 5y ago
If people could agree on what "look good" means, I don't think it'd be impossible to get the major browsers to update default styles. But every site seems to have a different idea of the look they want. I'd be curious to see a somewhat-objective look at what's actually wrong with default browser styles, separating out well-established usability and design considerations from personal preferences and branding preferences. I wouldn't be at all surprised if there are near-universal things wrong with the default styles, and those might be possible to change if they can be separated out.
- Swizec 5y ago
  Based on my experience as a web developer working with many designers over some 20 years of design trends, here’s the problem: Default styles aren’t pretty. That’s it. They’re superior in every other way. You always know what to click, you always know what an element will do, how it behaves, the UX is consistent with your OS, etc. Default elements are fantastic.
  - markdown 5y ago
    Not datepickers. The datepicker element is garbage.
    - admax88q 5y ago
      Too true
  - felixfbecker 5y ago
    > the UX is consistent with your OS Buttons in Chrome on macOS look completely different than in native apps. Buttons and context menu in Chrome's native <video> controls look yet again different, following Material Design. From the things one could argue are good about native browser styles "consistency with the OS" is definitely not one of them.
tanaypingalkar 5y ago
You can reset your css
- lolinder 5y ago
  For some elements, yes. Many others have certain attributes that are completely unstylable, a lot of browser-specific attributes and selectors (not just prefixed attributes but also whole pseudoclasses), or both.
robin_reala 5y ago
Who cares about looking good, when we’re talking about working good? Of course, it’s worth putting the effort in to both looking good and working good, but if we’re going to pick one, we should go for the second.
- worik 5y ago
  I think that is a false dichotomy.
- lmm 5y ago
  If we're a business then looking good and mostly working ok probably sells better than working good and mostly looking ok.
  - brailsafe 5y ago
    I feel like this is only true in cases where either your product is your appearance or it's highly unlikely the thing you're selling can be returned.
loloquwowndueo 5y ago
A div looks like nothing by default. It’s probably about the same amount of effort to make a button look good.

austincheney 5y ago

The one exception for me are forms. In that case I would rather use a div or section tag with role=“form”. I have seen less experienced developers do weird things with form tags and submit event and form tags have unique behaviors associated and requirements.

brailsafe 5y ago
I've never heard of this. Could you elaborate on why you'd not use an actual form element?
- austincheney 5y ago
  Forms cannot be nested. That is an html violation. That is because all submit events fire on all nodes contained by a form on submission even if the page does not go anywhere. Forms also require an action attribute that contains a submission address, which requests a new page on submission.
  - Varriount 5y ago
    What circumstances call for nesting form elements,?
    - testudovictoria 5y ago
      If a dev finds a form to be nested, it's usually because something was tacked on as an afterthought. I'm speaking from experience. I had a project that had applications associated with it. Forms are the natural way to express this. There were some disclosures associated with the application, and there was a modal associated with emailing the disclosures. I needed to add some front end validations to this modal. No matter what I tried, I could not get these validations to trigger correctly. I spent an entire work day on trying to get a library to work with this modal. It wouldn't work, because changing the modal's div to a form tag would cause errors or unexpected behavior due to the nested form tags. TL;DR: Nothing requires it. Devs might not understand the implications.
    - 5y ago