I realized I'd only added this fix to Packages; just added it to Options as well. This PR is ready now.

I did not tried it but I think the simplest solution would be to just add tabindex attribute to tr element (which has onClick handler) to make it focusable by tab. If this works we avoid any changes in HTML and CSS to get this functionality. On the other hand using a element provides additional semantics which are good for accessibility.

My understanding is that while there is an agreement that the issue should be addressed, the majority feels it should be addressed together with planed redesign and that it's not important to roll out quick-fix soon. But perhaps if enough people feel like this should be fixed ASAP we can discuss quick fix independent of a redesign.

Did you try the changes out? display: table-row causes the <a/> tag to display like a <tr/> tag, so this is perfectly fine. With this change the website appears identical to how it did before.

I'm not sure what you mean by 'not correct' but this is definitely a valid solution to the issue.

I agree that inline styles aren't the best practice - I cam move those.

@samueldr mentioned in the issue I opened that an html tag should be used rather than tabindex as the browser already defines behavior for interacting with HTML tags and tabindex can be finicky.

My suggestion wrapped the first cell's content:

• https://github.com/NixOS/nixos-homepage/blob/b60ed4af1f3b94b9415312249a8725fbff6ab2aa/packages-explorer/src/gui/result.js#L33-L40

(Here it's a button, but an <a>nchor can also be used if we have a real href to point it to)

The main drawback with wrapping only the first element with a link is that the "whole row" won't be selected by keyboard navigation, but that's not really an issue.

I'm not sure what you mean by 'not correct'

It's indeed not correct semantically. It is correct in terms of display/render but there are other ways in which HTML/DOM structure can be incorrect which can lead to problems other than rendering in browser.

an html tag should be used rather than tabindex as the browser already defines behavior for interacting with HTML tags and tabindex can be finicky

I've seen @samueldr 's comment I think he is right just for a different reason than that the bahaviour of tabindex is unreliable in some way. I agree that using a is more correct in terms of semantics. Semantics matter for things like accessibility (screen reader assistant software etc.). I believe what he argues for is that there are other things to improve beyond just allowing tab navigation. These are related to each other and that it would make sense to consider them together. Click actions on unexpected elements can simply make it impossible for some types of software to assist user effectively and should be avoided. @samueldr can you maybe clarify if we're on the same page?

I agree with both @garbas and @samueldr. However in my opinion the best quick fix route would be tabindex since that doesn't make situation around semantics much worse and is simple. With redesign though we should avoid click and tabindex on tr in favor of element like <a> or <button> which are expected to have click actions.

@samueldr actually regarding:

The main drawback with wrapping only the first element with a link is that the "whole row" won't be selected by keyboard navigation, but that's not really an issue.

What if we would do exactly that and just remove the "only". We can keep both button as well as event handler on <tr>. That way tab:

• for mouse users we would keep convenience of having whole row clickable
• tab selection would simply work via buttons
• to meet the accessibility standard we would have button as well (an element that is expected to have action on click).

What if we would do exactly that and just remove the "only". We can keep both button as well as event handler on . That way tab

To remove the "only", three scenarios:

• wrap the whole <tr> → broken HTML.
• stop using a <table> → need to re-implement styles (possible with upcoming redesign).
• add as many <button> as columns → need to tab through the whole row before going to the next.

But, uh, now that I look at your solution, what you implemented is what I had in mind, and I see the miscommunication. I didn't intend to make only the first cell clickable, I was only thinking about adding one focusable element per row.

This has been solved in #260. @jakeisnt thank you for bringing this issue up.