This implementation has a nice a pretty design and the animation is slick, but it has some important issues that should be addressed. These issues make the whole tab component non-accessible and unusable for many people.
Probably, the top issue is that the tabs are paragraphs but they should be buttons (or maybe even anchors). Because a <p> is not an interactive element, it doesn't get focus. Keyboard-users are then unable to interact with the tabs and change the active panel. Also, the tabs cannot be activated from screen readers either.
Because of how the content is organized and displayed, screen reader users will have to go through all the tabs before reaching the content after them (and depending on the content of the tabs, keyboard-users may have the same issue.) This can be a little bit trickier to implement and resolve considering the animation, but it should be possible.
Accessibility aside (although related to it), there's one more thing: the use of the proper semantic HTML is important. H1 is the main page header and a general recommendation is to limit it to only one per page (not always), there is an <h1> in each tab panel, which can be confusing. It would probably be better if they were <h2>. Also, the <hr> has some semantic value that makes it not needed between header and content, it would be better to have a bottom border/shadow in the header instead.
Apart from that, the article is good and the component looks amazing. Looking forward to reading more from you.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This implementation has a nice a pretty design and the animation is slick, but it has some important issues that should be addressed. These issues make the whole tab component non-accessible and unusable for many people.
Probably, the top issue is that the tabs are paragraphs but they should be buttons (or maybe even anchors). Because a
<p>is not an interactive element, it doesn't get focus. Keyboard-users are then unable to interact with the tabs and change the active panel. Also, the tabs cannot be activated from screen readers either.Also, a tab panel is one of the components that cannot be done semantically with HTML "out of the box." It will work, but it can be made more accessible using aria-attributes to help identify the different parts of the component. The W3C has an example with a suggested way of adding these aria-attributes and roles.
Because of how the content is organized and displayed, screen reader users will have to go through all the tabs before reaching the content after them (and depending on the content of the tabs, keyboard-users may have the same issue.) This can be a little bit trickier to implement and resolve considering the animation, but it should be possible.
Accessibility aside (although related to it), there's one more thing: the use of the proper semantic HTML is important. H1 is the main page header and a general recommendation is to limit it to only one per page (not always), there is an
<h1>in each tab panel, which can be confusing. It would probably be better if they were<h2>. Also, the<hr>has some semantic value that makes it not needed between header and content, it would be better to have a bottom border/shadow in the header instead.Apart from that, the article is good and the component looks amazing. Looking forward to reading more from you.