From Front Desk to Frontend p.35 Building an Accessible Toggle 2/3

#webdev #javascript #fundamentals #accessibility

Cover photo by Madison Inouye on Pexels, search word was "high contrast"

Hi, I'm Tauri!

I am a Front End Developer and a student (and enrollment counselor) with Skillcrush, the online coding and design school with a heart! I am looking for employment with a company, and working on adding to my skillset every day! This blog is chronicling my most recent projects, so thank you for reading!

This week I've been celebrating Pride Month by going to the Lesbians Who Tech Pride Summit! SO many amazing talks and high quality connections made! This event last year is what helped me to come out of the closet in the workplace.

Some of my favorite talks were about AI, centering black voices, and there were so many amazing talks about accessibility! There are multiple stages with talks every half hour to an hour for five days straight, so it's A LOT and I get some of my most quality networking done at these conferences so I made a lot of amazing connections! Some of my favorite speakers was the CEO of OpenAI of ChatGPT fame Sam Altman, and Gabrielle Union, but once I get the recordings and can take some time with the material I'll be cataloguing more!

Monday 6/12/23:

I started workshopping my personal branding in a workshop with Skillcrush today. It definitely needs a refresh and an energy-injection! I started with messing around with my personal tagline, and all I pushed to Github today was the new one I'm trying out on my portfolio hero section and in my resume. This started me on my journey of realizing that my particular niche and passion of interest is in accessibility! Even when it makes supposedly simple elements a little more complicated, I truly love digging my feet in when I know the outcome will be more accessible websites. This is what I want to pursue more of in my career.
Today I also collected some resources on how to use aria-pressed with Javascript for my accessible toggle.
Here's what I found to dig into on Weds, and what looks like a treasure-trove of accessibility resources (bc Tue eve I'm spending time with family):

Tuesday 6/13/23:

I had a little bit of time before visiting with my family to start working on my toggle JavaScript more, and I've just been eager to get going.
I brought the background-color change for the toggle-display into the CSS class for the checked-state and aria-pressed state "true" so that it would go from gray to purple, but I'm not going to see that change until I get it triggered with event-handlers and listeners in JS.
The resources I found yesterday were super useful. dair and ADG gave me more background reading on aria-pressed. Aria-pressed is super useful for screen readers because it reads out loud "Toggle. Button not pressed." when accessing the element then updates to "Pressed" once activated. ADG says that using a checkbox is a more robust version of this, but doesn't go into why. Kitty Giraudel's blog on building an accessible toggle uses a checkbox when the toggle + changes utilize CSS only, but a button with aria-pressed when calling JS, so I'm rolling with that.
The Web3C Web Accessibility Initiative is the best resource I found on how to create accessible JS for my toggle, including a clear indication to allow it to be activated with the space and enter keys which I've done before but I haven't been practicing layering them for accessibility with all my buttons so with this in-depth project I will certainly be doing that from here on. The Web3C resource had code for both an action button (ex. a print button) and for a toggle button(ex. mute/unmute) so I referred to the script for a toggle button. I right out copied the code under my currently existing JS in a commented-out form so that I could start parsing through it for my own usage, and anticipate that I may have to tweak the HTML markup more as well to get everything working smoothly.
That's all I had time for today.

Wednesday 6/14/23:

As an added little bonus to the tech test I took last week, I decided to use the Frontend Mentor ReadMe format for the ReadMe I included and by looking that over I learned how to share a code block properly in Markup. Also by observing the JS comments in Web3C WAI I learned how to make an extended comment in JS that spans multiple lines (I used to // out every single line, how crass 🎩). So here's to clearer write-ups from here on! 🍻
So doing a quick overview of the JS example included with Web3C WAI, including the CodePen linked on main page, I can see that the event listeners are added in a function named function init that is pulled into the onload stage of the lifecycle of the page with a window.onload = init; at the end.
I can't see the header of the HTML, but I was taught to defer the loading of the JS to after the rest of the HTML and CSS has uploaded to make for a fast uploading exp by allowing the HTML to load first + to make sure all HTML has uploaded first so that the JS can modify it. This is another question I'll be asking the Frontend Mentor community. ⭐ After the eventListeners are all added in this function, the eventHandlers are set up in functions afterwards.
I'm going to stick to the structure I learned and declare the variables by themselves at the beginning, then create each eventListener function with the eventHandler immediately following.
Other than naming the variables today, there was a lot of reading I did regarding @param on our own dev.to and what event.currentTarget on mdn webdocs and w3schools. And CSS Tricks on key codes.

Thursday 6/15/23:

I was really pooped today! LWT is such a 💥 of the heart and mind! Once I finished work I couldn't really help but just faceplant on my bed for a nap.
I did get a little more reading done tho. This explanation of event.currentTarget on our own dev.to really helped me to understand what exactly was going on in the different structuring of the event listeners vs event handlers that I was seeing in the JS template by Web3C WAI. So I can still use my defer attribute in for the JS script sheet, but the event listeners are added at the onload of the window and delegated as needed to the event handlers which are put in a separate place bc having multiple event listeners per every single event handler increases memory usage, and decreases performance! So I'm growing to understand and appreciate what's going on with this template by the day.

Friday 6/16/23:

So now that I'm understanding the template code I'm starting to remove the comment-out regions I had set, and I noticed that VS Code is crossing out keycode everywhere that something is written like event.keycode === 32! When I hover over this VS code VERY helpfully told me this feature is deprecated! And it directed me to the MDN Webdocs explaining why, primarily that it is not compatible with different keyboard layouts around the world.
KeyboardEvent.code is preferred instead and is now fully supported across browsers. This matches to the position of the keyboard, even across different layouts. I'll be emailing this part of my blog series to W3C WAI per their Terms of Use when I complete the toggle next week, so I'll let them know about this then!