Hi, Njeri, I'd like to challenge a couple of the examples you've shared here.
You've used the role attribute in a lot of places where it is inferred -- for the nav, button and form elements; see, for example, MDN:
Using the <nav> element will automatically communicate a section has a role of navigation. Developers should always prefer using the correct semantic HTML element over using ARIA.
If there's more than one nav element on your page, it can be helpful to add an aria-label to distinguish them. But, just like the tweet you included from Steve Faulkner said, no ARIA is actually better than bad/unnecessary ARIA markup.
role="menu" isn't ideal or recommended for site navigation; see details here.
Any mention of tabindex should make clear which elements already receive focus (ie, <a href="#" tabindex="0"> is not necessary) and that declaring a value positive tabindex on any item can result in needing to set tabindex values throughout your layout, which is a headache.
Also, the code example under #5 "Sections" is missing the closing </div> -- though, if you're using role="main", maybe a main element would be better than a div?
I took a stab at commenting and updating your CodePen here. There's a lot of outdated and confusing info about accessible markup online, so I hope this doesn't discourage you -- keep exploring and learning 😁
Certainly! I love feedback. What would be the best way to tab through dropdown menus or adding non-visible options to skip tabbing through some sections of a site (in the event that there is a long sidebar)? I have a few buttons that I'm adding and want to make sure that safari knows that they are tabbable. I read a posts like this that made me want to ensure that all browsers index every button, every time.
Wrapping all content in a main tag would be more optimal. I'm going to implement the edits you made. Thanks so much for taking the time to do that.
My email form is animated with CSS (accessible CSS and javascript coming in pt 2). It looks a little weird in plain HTML, email form animation here.
Yes, there's so much old web accessibility content out there. It was really hard to find things that are relevant. While doing research on the subject, it seemed as if the topic had become a forgotten folklore of the web. Are there any other resources or lists where I can get more up to date accessibility practices?
Not the OP, but I think I might be able to answer a few of your questions there.
For dropdown menus, there are a few ways to satisfy accessibility according to the standards in WCAG 2, but I typically like "Approach 2" on the W3C page on Fly-out menus. This method ensures that keyboards and screen readers get the advantage of a mouse user by being able to jump past content that is irrelevant to them and then choose when to expand the menu.
As for your question on making sure elements are tabbable, there are a number of elements that inherently are tabbable, no additional code required. Key examples are <a> (assuming it has an href attribute), <button>, <input>, <select> and <textarea>. All browsers do this automatically.
It is generally never recommended to use tabindex unless you are using the -1 value to remove an element from the natural tabbing order (or creating a target for tabbing), or the 0 value to give an element tab focus that does not normally receive it. The order of tab focus is predetermined by the order in the DOM (therefore, the way to make your site accessible for tab order is to make sure the order of elements in code is the same order you expect a user to read the content).
If you want up to date information on accessibility practices, I would definitely use the W3C Web Accessibility Initiative resource and I'd also highly recommend WebAIM as well.
Thanks for writing this article as well, spreading the word about accessibility is definitely important, especially as it becomes more of a requirement for many organizations.
Hi, Njeri, I'd like to challenge a couple of the examples you've shared here.
roleattribute in a lot of places where it is inferred -- for thenav,buttonandformelements; see, for example, MDN:If there's more than one
navelement on your page, it can be helpful to add anaria-labelto distinguish them. But, just like the tweet you included from Steve Faulkner said, no ARIA is actually better than bad/unnecessary ARIA markup.role="menu"isn't ideal or recommended for site navigation; see details here.Any mention of
tabindexshould make clear which elements already receive focus (ie,<a href="#" tabindex="0">is not necessary) and that declaring a value positivetabindexon any item can result in needing to settabindexvalues throughout your layout, which is a headache.Also, the code example under #5 "Sections" is missing the closing
</div>-- though, if you're usingrole="main", maybe amainelement would be better than adiv?I took a stab at commenting and updating your CodePen here. There's a lot of outdated and confusing info about accessible markup online, so I hope this doesn't discourage you -- keep exploring and learning 😁
Certainly! I love feedback. What would be the best way to tab through dropdown menus or adding non-visible options to skip tabbing through some sections of a site (in the event that there is a long sidebar)? I have a few buttons that I'm adding and want to make sure that safari knows that they are tabbable. I read a posts like this that made me want to ensure that all browsers index every button, every time.
Wrapping all content in a main tag would be more optimal. I'm going to implement the edits you made. Thanks so much for taking the time to do that.
My email form is animated with CSS (accessible CSS and javascript coming in pt 2). It looks a little weird in plain HTML, email form animation here.
Yes, there's so much old web accessibility content out there. It was really hard to find things that are relevant. While doing research on the subject, it seemed as if the topic had become a forgotten folklore of the web. Are there any other resources or lists where I can get more up to date accessibility practices?
Not the OP, but I think I might be able to answer a few of your questions there.
For dropdown menus, there are a few ways to satisfy accessibility according to the standards in WCAG 2, but I typically like "Approach 2" on the W3C page on Fly-out menus. This method ensures that keyboards and screen readers get the advantage of a mouse user by being able to jump past content that is irrelevant to them and then choose when to expand the menu.
As for your question on making sure elements are tabbable, there are a number of elements that inherently are tabbable, no additional code required. Key examples are
<a>(assuming it has anhrefattribute),<button>, <input>, <select> and <textarea>. All browsers do this automatically.It is generally never recommended to use
tabindexunless you are using the -1 value to remove an element from the natural tabbing order (or creating a target for tabbing), or the 0 value to give an element tab focus that does not normally receive it. The order of tab focus is predetermined by the order in the DOM (therefore, the way to make your site accessible for tab order is to make sure the order of elements in code is the same order you expect a user to read the content).If you want up to date information on accessibility practices, I would definitely use the W3C Web Accessibility Initiative resource and I'd also highly recommend WebAIM as well.
Thanks for writing this article as well, spreading the word about accessibility is definitely important, especially as it becomes more of a requirement for many organizations.
Thank you, @sg667 . I will make sure to check out W3C's accessibility page.
Great response, @sg667 👍🏻