Hacker News Reader

Comment by chrisjshull | Hacker News Reader

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.

View on HN

> In short, if there is a semantic element that matches your need, use it.

Yes! This is known as The First Rule of ARIA.

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

It would be equal effort to restyle something done with ARIA compared to a semantic element, yes?

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.

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.

Unfortunately, Firefox recently actually stopped making semantic elements look native (=good).

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.

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.

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

Not datepickers. The datepicker element is garbage.

Too true

You can reset your css

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.

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.

I think that is a false dichotomy.

If we're a business then looking good and mostly working ok probably sells better than working good and mostly looking ok.

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.

A div looks like nothing by default. It’s probably about the same amount of effort to make a button look good.

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.

I've never heard of this. Could you elaborate on why you'd not use an actual form element?

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.

What circumstances call for nesting form elements,?

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.

working with web forms https://docs.microsoft.com/en-us/aspnet/web-forms/ (Oh the nightmares!)

None. There is no good reason to do this. It doesn't stop people from doing it.

Not the same thing as nesting forms, but when faced with similar challenges I found the <input form="form-id" /> attribute[0] is a good solution.

The trade-off is that you have to specify it almost every single time, but it lets you group form elements that for UX purposes belong together, but for other reasons need different forms.

[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

Does that still allow you to press "Enter" in an input field to submit the form, or do you have to build your own kludge to replicate that? If so, that sounds like that would invite only more weird things...

    onkeydown=function(event){if(event.key==="Enter"){mySubmit();}}

You are clearly overthinking the challenge.

You are clearly underestimating the compatibility & accessibility challenges of reinventing the form submission code of a web browser from first principles.

Believing you can do so and not fuck it up is sheer hubris, not to mention, wrong. Doing so because you don't like the browser edge cases, is how websites end up suffering from even more edge cases, and harks back to the bad old days of "Sorry your browser is not supported".

Financial institutions are amongst the worst offenders - ironic since pulling this kind of naïve stunt vastly increases the attack surface. I've been in a position to redesign financial institution systems and rewrite their technology policies, and when doing so this kind of off-standard NIH crap is something I seek to stamp out.

Want to submit a form? Use a damn form, with a plain old submit button, and rely on the standard behaviour. Want to put some UI polish around it? Progressively enhance the standard behaviour.

What not to do: imagine you can write better UI<>protocol interaction code than that already in Chromium and Webkit, or hope to infer and reimplement the behaviours of any more specialised user-agents.

> What not to do

What you said. Most of what you said is common anti patterns. The reason is web technologies are built around a few set of standards that are designed for extension, such as the DOM and WCAG. Fearing those standards for a small set of static principles is common but that doesn’t make it smart. That’s why this technology space is so hostile to originality. You mentioned NIH but the more common problem is: https://en.m.wikipedia.org/wiki/Invented_here

Stop being so afraid and hostile. Embrace how these technologies work and more easily achieve accessibility with less effort. If you are waiting for some tool, NPM package, or framework to do it for you it’s not going to happen.

onkeydown is not a “technology”.

Abusing standards with shoddy inner-platform reimplementations doesn’t make someone an innovator, it makes them as much a fool as the cargo-cult of the NPM ecosystem.

Strange, I always thought the greatest fools are the people who fear the titles they wear.

That is merely a corollary of the Peter Principle.

Your response is a bit harsh.

So you think it's safer to rely on every engineer adding that (and the other facilities provided by web browsers by default when using native elements) to every input field in a form, than relying on them not doing weird things with that one form tag?

If you train your teammates to do their jobs you won’t have anything to be afraid of.

But then why not train them to use <form> correctly? Since you mentioned the reason for not using it was that

> I have seen less experienced developers do weird things with form tags and submit event

When a form requires JS to be submitted, there’s a high probably that I abandon that website instead. My expectations of working plain HTML are never higher than with regard to forms. By all means, progressively enhance, but don’t be tempted by the hubris of claiming to know better than the user-agent how the user-agent should work. It’s not just rude, it’s a slippery slope towards systematic incompatibility, weirder bugs than the ones you were afraid of, and security holes.

> When a form requires JS to be submitted, there’s a high probably that I abandon that website instead.

You say that, but I doubt that in practice. If the form is your bank login or bill pay or anything else you are locked into I really doubt you will give up because of some personal opinion on JavaScript and instead spend the next 30 minutes calling somebody to complete a similar action over the phone.

The goal is to achieve accessibility as equivalently as possible, with as little enhancement as possible, and yet often not force a page change because of form submission.

Calling someone a liar to their face without checking their body of work first just leaves a lot of egg on yours.

That doesn't sound worse than not naming the inputs or coding the buttons for keyboard interaction, things inexperienced developers will do if they're not educated in the basics of semantic HTML (even those who do use inputs too often neglect to associate a <label> where they're called for).

Reply on news.ycombinator.com