hey y’all,
I just finished my portfolio site. If you could take the time to look at it and let me know what you think and how I can improve upon it. I would greatly appreciate it.
-Evan
1 Like
Hey Evan, I’m in PDX too, so I had to check it out.
The first thing I’m noticing is that I’m getting a horizontal scroll bar at all widths with both Chrome and FF. Granted, the scroll is not that big, but I would try to get rid of that.
Hey Bruce. Nice to meet a fellow Portlander on the forums. Thanks for taking the time to look it over. Was the horizontal scroll on all pages? or just on the projects page?
It’s on all pages for me.
Thanks, wasnt seeing that on my browser. Did some fiddling, and I think it’s fixed now.
Yes, I am no longer seeing the horizontal scroll bar.
Another issue I’ll bring up is the hamburger menu for narrow view ports. It isn’t currently accessible with a keyboard. If you wrap the <svg> in a <button> and then put the click handler on the button that will fix the immediate issue. You’ll also want to add the text “Menu” inside of the <button> (for accessibility) and then you can visually hide the text on the page.
Also, when the hamburger is visible you are hiding the nav menu with CSS, which is fine, but the menu itself is still active, so I can actually Tab through it with my keyboard even though I can’t see what I’m tabbing through. Whenever you hide an interactive element you want to take it out of the tab order. You can do this in a variety of ways. The easiest would be to set display: none on the nav <ul> when you hide it. If that doesn’t work for you because of the CSS animations you are doing then you can take it out of the tab order by setting the tabindex attribute to “-1” on each of the links in the menu when it is hidden, and then setting tabindex back to “0” (the default) when you show the menu.
But setting tabindex="-1" still won’t keep screen reader users from seeing the menu, so you’ll also want to set aria-hidden="true" on the nav <ul> itself when it is hidden and then aria-hidden="false" when you show it. It can be quite a bit of work to hide elements accessibly, which is why display: none is the best way to do it if possible.
Also, I would move the hamburger button inside the <nav> as it is technically part of the navigation menu.
Good points. Thanks for the insight. I hadn’t really considered keyboard accessibility for this project when I started out. Looks like I have some work to do. I started a new branch but it’s gonna take some fiddling to reorganize and integrate the new bits.
I understand. I hope it didn’t feel like I was calling you out on this too much. My intent was just to make you aware of some accessibility concerns you might not have been exposed to. In my opinion, accessibility should be included at the very beginning of the process instead of something that is learned after you have mastered the black arts of web development.
My suggestion would be to always test everything you do with a keyboard only. You should be able to use the keyboard to perform all functionality on the page and you should be able to see where your keyboard focus is at all times. There may be exceptions to this rule, but they are few and far between.
Have fun!
oh not at all. Actually the in depth explanation is really helpfull and I’ve been working the last couple hours on trying to implement it. Accessibility is very important to me. I used to work for individuals experiencing disabilities. I want all of my sites to be accessible. Your post is a good reminder.
after you have mastered the black arts of web development
Thanks!
1 Like
Hey, @bbsmooth so I made a tab accessible nav bar. I was wandering if I could get your opinion on it before I add it to my site?
Hey @edubz, you are definitely on the right track.
Semantically, you can’t wrap the <li>s in <a>s though. The <li>s must be direct children of the <ul> and then you put the <a> in the <li>. Also, you don’t want to add tabindex="0" to the <li>s. The only elements that should be active in the list are the <a>s. You can (and should) however set tabindex="-1" on the <a>s when the menu is hidden, which will prevent the user from Tabbing on those.
You also don’t need to add tabindex="0" to the <button> since it already has that by default.
If you really want to be accessible, there are a few extra things you can do behind the scenes:
-
When the menu is hidden, add the attribute
aria-hidden="true"to the<ul>. This will hide it from assistive tech such as screen readers. Just make sure to either change it toaria-hidden="false"or remove thearia-hiddenattribute completely when the menu is shown. -
Since the button controls the visibility of the menu, you will also want to add the
aria-expandedattribute on the button. When the menu is hidden, setaria-expanded="false". When the menu is showing, setaria-expanded="true". This attribute tells screen reader users the state of the button and then they will know whether the menu is showing. -
Furthermore, you will also want to make it clear to screen reader users that the button controls the visibility of the menu. In order to do this, you will first need to add an
idto the<ul>. Then on the button you will addaria-controls="id"where id is the id of the<ul>.
It does take a little work to make a hamburger menu accessible. I’m glad you are interested in this stuff and are trying to make it right. If you want to do this professionally then accessibility will be an important part of your job (or at least it should be).
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.