Here’s my take on the drum machine project. It does pass fcc’s automated tests though I did have to use some vanilla javascript to do so. The game boy is all css and the background is only visible on computer screens and tablets. This makes your phone into a game boy, kinda. Oh - this is the first project I’ve built using the Vue CLI. It took me a week to find my way around, but I really like building in this environment so much better than linking in scripts via cdn’s.
I like this one a lot. Very creative. I know you are trying to emulate the look of a Game Boy, but since this is a web based application I have to evaluate it as such. A few issues:
- The black letters on dark purple do not have enough color contrast and are thus not accessible.
- If I shorten the browser window so that the Game Boy is taller than the window I do not get a vertical scroll bar.
- Because these are buttons, they should technically have an outline on them when focused (or at least when focused using the keyboard).
- Increasing the text size causes the following styling issues:
- The bottom row of buttons break out of the Game Boy.
- The letters are not centered on the buttons any more.
- The Game Boy travels up the page until the top of it becomes cut off
- The text in the green screen breaks out of the screen .
Overall this is very nicely done. Most of the issues above are cosmetic and don’t break the functionality. But if you like a good challenge of trying to make this responsive at any text size and any width/height then hopefully I’ve given you a few things to think about.
1 Like
Thank you so very much, @bbsmooth ! I tried addressing your list of issues in order below and have some questions, too:
- I changed the color of the letters to improve contrast.
- Resizing the browser window will show the scroll bar now.
- If they’re not buttons anymore, the don’t need to have the outline on them anymore, right?
I changed them to generic div’s to keep the look sleek. However, I feel like this is cheating (the user’s ability to use the site). But not really, since keypresses activate the action. Thoughts? - How can the user increase only the text size? Zooming the site makes everything zoom together. If I go into the console and change the root font-size, ya things break. What am I missing? Any advice of having everything scale? Like I used rem units for some divs, but px for others. Should I use rem or % for my app divs so they contain the larger text (that I can’t figure out how the user can change)?
Thank you again for taking the time and offering your detailed and informative feedback.
Concerning the buttons, you don’t want to change them to divs, you had them correct as buttons the first time. Change them back. The button element gives you all the accessible keyboard functionality you need. Divs do not. I understand your concern about looks, but you should not sacrifice accessibility for it. When the keyboard focus is on a button there should be an indicator on that button. It doesn’t have to be an outline, you could use a border, or go with a different background. You would do this using the :focus pseudo class for the buttons. If you really wanted to, you could limit the focus indicator to just keyboard input. There is a way to determine if the user clicked the button with the mouse or keyboard (I will leave that up to you to figure out). Bottom line, when using a keyboard I should be able to see where the current keyboard focus is on your page.
As far as increasing text size only, using FF, go to the View - > Zoom menu and activate ‘Zoom Text Only’. While holding down the Ctrl key, scroll your middle mouse button to increase the text size. The letters on your buttons are behaving better now (they are only offset a little) but the Game Boy itself is still moving up the page (though not as much as last time I checked). The biggest issue remaining is that the sounds with longer names are still breaking out of the green screen.
There are also browser extensions that will allow the user to increase the text size. I just find the method above easiest to use when evaluating web pages. I highly recommend you always do this with whatever projects you are working on. And give it a try on any web sites you visit. You’ll be surprised how many of them start to fall apart after increasing the text size even a little.
1 Like
Okay. Returned to buttons. For the focus style, I turned to :focus-visible. However, not every browser supports it, or if it does the user needs to explicitly turn in on, or like firefox it’s called something else entirely. Good thing there’s an official polyfill. It took me some time to implement it (new skills, yay!), but the focus should only show on keyboard navigation and not on mouse/finger clicks.
As far as the app scaling goes, I haven’t addressed that, yet. However, I did find how to scale just the text and now see what you do when scaling. I’m pretty sure it’s because I’ve mixed pixels and rem in sizing my component. Initially, I aimed for getting a scale of the original Game Boy screen (for coolness). I think I can still achieve that, but will need a little more time. Thanks again for pointing this out; it’s not an issue that I’ve ever considered or really seen mentioned.
I’ve also refactored the css so that’s it’s mobile-first. Again, didn’t really think about it. I’m also going to implement Open Graph soon. So many little extras to learn!
Awesome job on the keyboard focus. It looks very nice and doesn’t detract from the overall look. Learning new things is part of the fun! I’m guessing that any future projects you work on you are going to think about keyboard focus now 
1 Like
The app scales when zooming the entire page or zooming just the text. I changed all the px values (save the root font-size) to rem values. I think I’ll be avoiding using pixels for zoom-ability in the future. I’ve also added Open Graph meta tags for social sharing.
Thank you so much for the time you’ve given. I’ve learned lots!
Wow, that is looking real good. Congrats on a job well done.
I’m going to be real picky here, not because I am trying to find something else to ding you with, but rather because I can tell you are like me and strive for perfection
- As I increase the text size the Game Boy still travels up the page and at a certain point the top of it is cut off and I can’t scroll up to see it. I can still scroll, just not all the way up. If I go to 300% text increase it pretty much cuts off the text in the green screen. I was able to fix this with a three additional CSS properties on #app-container.
- Technically, your page should have at least an h1 header (Something like “Game Boy Drum Machine” maybe?) If you don’t want it to show on the page then you can hide it visually so that screen readers will still see it:
https://a11yproject.com/posts/how-to-hide-content/
Personally, I think a nice header at the top would look good. You and I both know what this is, but others may not. - The content should be in a “landmark” which in this case means that it should be wrapped with a
<main>tag. But you can also userole="main"on either #drum-machine or #app-container.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/Main_role
And if you think I’m crazy about accessibility now, the next step would be to download a screen reader and try using it with your app and make the necessary adjustments/additions where needed. If you are interested in trying this, for Windows the two most popular are NVDA and JAWS. For Macs it is VoiceOver. There is a slight learning curve though, so be prepared to spend some time reading about how to use them.
One thing that I think would really help people who can’t see this page are instructions. You wouldn’t even need to include them on the page itself, you could make a link to a separate page. Another thing that might be helpful is more descriptive text for the buttons. You could do this by using the aria-label attribute:
When a screen reader reads the button it is just going to say the letter associated with the button (so when the tab focus gets to the “Q” button it is just going to say “Q”). But we also see the name of the sound in the green screen. Thus, that button represents not just a letter but also the name of a sound. So both of those pieces of information should be provided to the screen reader, which aria-label will allow you to do.
Speaking of the green screen, I would be inclined to hide it from screen readers completely using aria-hidden=“true”. It does provide information, but if you do the aria-label on the buttons then it is just providing duplicate information and is therefore not needed.
OK, I’ll stop now. This has been a lot of fun and I can tell that you are going to be successful at this if you want to be. Have fun coding.
1 Like
I think I finally fixed the zoom, scroll, and cutoff issue!
(Properly) hidden h1 header added, and I changed the default display message to “Game Boy Drum Machine” as a way to announce what this little app is.
I added role=“main” to #drum-machine.
I dynamically added descriptive aria-label tags to each button. For example, “press Q for ARP”, which is still less than helpful but moreso than before. I like the idea of adding instructions. Could these be hidden as well? I was thinking of adding a hidden paragraph after the header. I was going down your list and was thinking that the display is going to be redundant with the new aria-labels, and hey! there you are with the aria-hidden suggestion.
I’m running Manjaro linux distribution, so I’ll find a screen reader on my own and play with that soon. I’m even more excited to start my next project: the javascript calculator!
You’re feedback has been invaluable! Lots of fun indeed, and thank you for the encouragement. It means a lot to me.
Also, thanks for directing me to https://a11yproject.com/. That site seems like a comprehensive way to really learn about accessibility.
Yes you did, nice job.
I’m running Fedora myself. Linux has a screen reader called Orca, but to be honest, it isn’t really that good and not something I would use for actual accessibility testing. Go ahead and use it to play around, but that’s about it.
I run Windows 10 in Virtual Box and do all of my screen reader testing there. If Apple would allow you to run their OS in a virtual machine then I’d test on Safari as well. But they don’t and I’ll be damned if I’m going to shell out that type of money just to be able to test their crappy product (OK, can you tell how I feel about Apple).
1 Like
My Thinkpad T440p has a Windows 8 license on the motherboard, so I dual boot (I think there’s still a way to upgrade to 10 but I’m lazy). I’ll switch over to try the screen readers; thanks again for the suggestions. Apparently, there’s also a way to Hackintosh on this laptop, too, but really it’s so easy for me to get distracted. But ya, once I learned about Thinkpads and linux, why bother with Apple? haha