JSJ 444: Coding Front-end JavaScript for Accessibility with Neha Sharma
In this episode of JavaScript Jabber we interview Neha Sharma about the importance of coding front-end JavaScript with accessibility in mind. She explains practical methods in which to generate accessible UX when using front-end frameworks, such as React and Angular. For example, the importance of generating proper semantic markup, and considering behaviors and responses to user interactions.
Special Guests:
Neha Sharma
Show Notes
In this episode of JavaScript Jabber we interview Neha Sharma about the importance of coding front-end JavaScript with accessibility in mind. She explains practical methods in which to generate accessible UX when using front-end frameworks, such as React and Angular. For example, the importance of generating proper semantic markup, and considering behaviors and responses to user interactions.
Panel
- AJ O’Neal
- Aimee Knight
- Dan Shappir
Guest
- Neha Sharma
Sponsors
- Scout APM | We'll donate $5 to the open source project of your choice when you deploy Scout
- The Complete Software Developer's Career Guide - Grab a Copy Today
React Native Remote Conf 2020
Picks
Neha Sharma:
- Follow Neha on Twitter > @hellonehha
- Nader Dabit (@dabit3)
AJ O’Neal:
- Microservices Parody
- AHA Programming
- Windows 10: tar, ssh, curl, pwsh
- Yellowstone
- webinstall.dev
Aimee Knight:
Dan Shappir:
Follow JavaScript Jabber on Twitter > @JSJabber
Special Guest: Neha Sharma .
Transcript
DAN_SHAPPIR: Hello everybody and welcome to JavaScript Jabber. Today on our panel we have Amy Knight.
AIMEE_KNIGHT: Hey hey from Nashville.
DAN_SHAPPIR: And AJ O'Neill.
AJ_O’NEAL: Yo yo yo, coming at you from Pleasant Grove, live.
DAN_SHAPPIR: And today I'm the host Dan Shapir and our guest today is Neha Sharma. Hi Neha.
NEHA_SHARMA: Hi Dan, hi everyone.
Your app is slow and you probably don't even know it. Maybe it's fine in most places, but then the customer loads the page up that one page and after a couple of seconds, their attention disappears into Twitter and never comes back. The reality is there are performance issues in your app and they're affecting your customer experience. What you need to do is hook up your app to a Scout APM and let it start telling you where the slowdowns are happening. It makes it really easy. It tells you how slow things are and what the problem is, like N plus one queries or memory bloat. It's also built for developers. So it makes it really easy to identify where the fix needs to go. I've hooked it up to some of my apps and I saw what I needed to fix in a couple of minutes. Try it today for free and they'll donate $5 to the open source project of your choice. Just go to scoutapm.com slash dev chat and then deploy it to your app. Once you do that, they'll donate the five bucks that scoutapm.com slash dev chat.
DAN_SHAPPIR: So Neha, you're coming to us all the way from India, correct?
NEHA_SHARMA: Yes.
DAN_SHAPPIR: It's pretty late there. I hope you've like rested today so that we will have an exciting podcast because I know we're talking about a really interesting topic and that topic is accessibility in JavaScript web applications. But before we start talking about that, can you tell us a little bit about yourself, who you are, what it is that you do?
NEHA_SHARMA: Sure. I have 10 years of experience in the front-end domain. Currently, I'm working as a UI manager and I'm pretty active in the community. I run a meetup group from the last five years in India, JS Lovers as well as I'm working on design systems and I'm pretty much vocal about accessibility, web accessibility to be very specific in India.
DAN_SHAPPIR: Well, it is a very important topic. And as I said before, we're going to be talking about accessibility today in the context of JavaScript web applications. So what's so special about accessibility in this particular context of JavaScript?
NEHA_SHARMA: We are in that time where we are talking or building the web applications with our very awesome frameworks like React, Angular, Vue. They are now actually taking the front seat in the front-end development environment. Now, these are JavaScript-based and most of the developers forget that they are still writing JavaScript. So when they look at the browser, they can see the web UI, but under the hood, there is no HTML. Everything is getting generated through JavaScript, which is not accessible. And there is the gap, though these frameworks do have in their documentation that how to support accessibility, but as a developer, many times we miss this out. And if you will look for the definition of accessibility, it says that it should be accessible to everyone irrespective of the disabilities. So that's why it is very important for the web developers to understand web accessibility in JavaScript and why it is very important so that we can make it, make the web accessible for everyone.
DAN_SHAPPIR: So suppose I'm building a web UI, web application, or a website using React. Can you give me a concrete example of where I'm likely to mess up accessibility or make the web page not properly accessible just because I'm using React with JavaScript rather than straight on HTML?
NEHA_SHARMA: Yes. So one of the common and the biggest mistake folks do when they are building a web application is they don't think about the semantic markup. Now if I will take the example of React, if the React developer is building a header component, instead of using the semantic header tag, that person will use div. Or if they are creating a button, instead of using the button semantic tag, which HTML provide, they will use div. As a result, that will not be accessible by keyboard as well as by the screen readers. So this is the most common and the biggest mistake folks do when they are building the application, either with React or any other framework.
DAN_SHAPPIR: In other words, if I'm analyzing what you're saying, they've kind of moved the semantic information or semantic context from the HTML itself over into the JavaScript code. That is, it's not a header because it uses a header element. It's a header because in the JavaScript, the name of the function that implements that React component is header. And that might be visible to the developer, but it's totally opaque to the actual person who's using the website, correct?
NEHA_SHARMA: Exactly. Correct.
DAN_SHAPPIR: I definitely agree in the sense that when I look at the HTML that's often generated by frameworks for single-page applications, it looks like a mountain of divs, which are useful elements. But really lack any semantic context. So I totally understand where you're coming from, but okay, so we have this problem. First of all, why is it so important to fix this problem? I mean, if so many people are doing it and we're living with it and are building successful applications with it, why is it so important to fix it?
NEHA_SHARMA: It's very important because we don't know who will end up using our application we are not controlling our users. So if you will see, there would be a person who is not able to access the mouse and that person will be 100% dependent upon the keyboard. So if your website is not accessible, the basic thing is if it's not using the semantic tags, the keyboard support would not be there. That person won't be able to access your application. So let's assume if it's an e-commerce application and you're application is not accessible, the user is not able to access it by using keyboard, then you are again losing a business. Now, think from the user perspective, this is a COVID-19 situation going on. There are a lot of people who are now dependent upon the digital apps to order food, to order utilities, even for the online education also. And so many apps are broke because of the accessibility and folks are not able to access it. So that's why it's very important, first, from the business reason. And second, there are folks who are dependent upon the digital platforms. And we, as web developers, who are building these applications, this is our, I'm not saying this is our responsibility, because web, by default, is accessible. So somewhere, we, as developers, are breaking accessibility. So we should go back and learn the basics and fix it
DAN_SHAPPIR: potentially quote-unquote quick fix is to add some area attributes into it. So for example, if I created a button component, but I created it just with a whole bunch of divs rather than an actual button element, is it sufficient for me to just add some area attribute that designates it as a button or am I losing out in some way by doing that?
NEHA_SHARMA: Okay, so this is a very good question because a lot of time people assume that if it's okay if we are not using Semantic, we will just throw a bunch of ARIA tags there. But if you are not using the right ARIA tag at the right place, you are actually hurting your application. So if there is a Semantic tag already available in our shemale, please use that because a lot of things that our browser is already taking care of that. For example, button which you just mentioned. There are a lot of things which go with button with respect of accessibility, like your screen readers are going to read aloud that this is a button. Your keyboard will get the X focus there by default and the on click behavior and everything. The moment you will throw an ARIA, you need to start handling a lot of such behavior by yourself. So first rule of ARIA is, if there's a semantic tag available, please use that. If not, they are already defined ARIA tags. You can just go and use from there. But do not try to put ARIA tag everywhere.
DAN_SHAPPIR: OK, now suppose, let's say suppose you convinced me and I'm going to try to be as semantic as possible. Before we talk a little bit about where I need to go to get this information, but suppose that I agree to do it. Still, how can I verify that I'm doing it correctly? Or put it this way, suppose I have an application that I've already implemented using React, and I think it's not sufficiently accessible, and I want to try to fix it. How should I go about it? What should be my process? Are there tools that can assist me? Are there processes? What should I do?
NEHA_SHARMA: So there are two ways through which you can go. The one thing is you can take the help of the tools which are already available, like examples, Lighthouse from Chrome. This is by default integrated with the Chrome Developer Toolbar. You can go to the audit section and there you will get it. There are X, which is very, very popular actually. So X, the extension of the Chrome is also available. You can use that. And there are a few more but these are the two which will help you the most. Apart from that, one thing we need to understand with the accessibility is, we cannot make everything automated. So because this is accessibility, we need to do the manual testing also. So if your application is already built, what you can do is you can run these tools, they will give you the errors, also they will give you the solutions, and you can fix that. And after that, what you can do is, you can just throw away your mouse and start doing the keyboard testing. The screen readers are also available with the Windows and the Mac. You can run that and do the manual testing also. And also one of the things you can do if you have the testing team available with you in your project, you can ask them to start doing the testing like this. So this is how you can do it.
DAN_SHAPPIR: But I understand what you're saying, but from my experience, framework-based web applications tend to be more, let's call it, dynamic than straight-on HTML, static HTML maybe that gets delivered from a web server. Even if dynamic HTML is delivered from a web server, it's more page-based. Whereas with single-page applications, you're often looking at complex flows and stuff being added or removed from a page based on user interactions. So I think that certainly tools like the ones that you mentioned that are built into the Chrome Dev Tools can be helpful. But they will mostly look at the static state of the initial render. They won't necessarily go through the entire flow of user interactions and stuff like that, I think.
NEHA_SHARMA: Yeah, that's true. And that's why we're the most of the testing comes with the manual for accessibility, because when it comes to accessibility, it is not, there are only set of few rules, but after that, it is more about the user experience. That for example, how a blind person is going to observe the information we are giving. Like you said that if it there would be a dynamic flow, then for that dynamic flow, if we are doing a screen reader reading testing then we need to understand by actually running the screen readers on that particular flow that is it making sense or is it not making sense or is there any information which is not coming out clearly for the folks. So there would be a lot of manual testing will go there.
DAN_SHAPPIR: From your experience for a moderate scale web application or website, how much effort is involved in such testing?
NEHA_SHARMA: There is a good amount of testing effort goes. The reason is also we folks who are testing, they are not actually having the experience of using the screen readers and everything. So first, they need to get comfortable with that. And then these need to actually start doing the testing. So in my experience, in my project, we have the testers who are who learn this and then they started doing the testing. So now the testing is pretty smooth but initially there was a lot of effort went to understand how the experience should be.
DAN_SHAPPIR: I understand obviously that from a moral perspective I think this is something that Tej has brought up in previous conversations that we had on this topic. So obviously from a moral perspective, there is total justification and need to properly implement accessibility. But as you just described, there's going to be a cost associated with it. There is the cost of doing the extra QA, of going through all the flows, fixing everything. There's probably a situation where the current application, as it's currently built, is not properly accessible. So I'm going to need to invest effort in making it more accessible. How do I justify this extra effort aside, again, from the the moral aspect, how do I justify it from the business aspect? Because at the end of the day, most software companies are out there to make money, like it or not.
NEHA_SHARMA: True, 100% I agree with you. This is one of the most common questions which comes to me. Giving the business justification or making a business case around it is the most difficult part, I would say, and convincing your leadership. The good thing is, in most of the countries, this is a law having the accessibility is by law. So when you talk, when you mention these things, you are able to build your case around it. Now, if I will talk about India, we don't have strict rules, we don't have strict laws against accessibility. So for me, it was a big struggle to make my leadership to understand that why we need it. But the strongest business case was that we don't know who is going to be our user, first thing. And second thing, if we want ourselves to place in a competitive market, saying aloud that we are an accessible product is definitely going to set us apart from the competition. So when you are able to pass this message that you are going to have a USP because we are going to focus a lot on accessibility, that will help you in building your business case. In my experience, this work, this actually helped me a lot. And I have seen that my leadership, they start calling it out, that we give accessibility a priority, and that's make us stand apart from the rest of the competitive products we have in the market.
Are you stuck trying to figure out how to get to the next stage of your developer career? Maybe you're just not advancing fast enough in the job you're in, or you're trying to break in in the first place or for whatever reason you keep going to interviews and it's just not working. You wanna land that dream coding job but it just doesn't seem to be working out. Well, John Sonmez has written a book for you called the Complete Software Developer's Career Guide. He walks through each stage of the development career and all of the things that you need to do in order to move up, keep learning, keep growing and find that next job that's going to get you where you wanna go. So if you're stuck and trying to figure this stuff out. Go pick up the Complete Software Developer's Career Guide. It's the number one software development book on Amazon. It's sold over 100,000 copies so far. I actually have friends of mine that reach out to me and go, hey, do you know this John Sonmez guy? Cause his book is awesome. So go get the book. You can get it at devchat.tv slash complete guide. That's devchat.tv slash complete guide.
DAN_SHAPPIR: Obviously, I guess you probably can't share like detailed financial information, but like in general, did you actually see an improvement in business as a result of focusing on accessibility?
NEHA_SHARMA: I don't have any such information, but yes, I can tell you that I can share with you that there was a positive response we got from our end users that we are also focusing on this before focusing on accessibility when we were not even talking about it. Though they never questioned it, but when we talking about it, they started appreciating it. So one gap I saw there is that a lot of our end users assume that everything which every company is delivering it would be accessible by default. So I would say the positive response which was coming might get converted to money and we will be getting some profit out of it.
DAN_SHAPPIR: Besides just making sure to use semantic HTML elements. We mentioned button, we mentioned header. Are there other things that are important from a technical perspective in order to achieve good accessibility?
NEHA_SHARMA: Yes, there are quite a few things which we should take care. So when we are creating the single page application, we are not refreshing our page. So our titles are not getting changed. Or if they are getting changed, we giving it back to the screen readers. Similarly, if any notification is coming on the page, or if it's a single application of e-commerce site, we are adding an item or removing an item. Basically, any DOM manipulation which we are doing, if we are not making using ARIA, then we cannot make it announce, basically we cannot announce it for the screen reader users. So we need to make sure any DOM manipulation or notification which is coming on our page, it should get announced. Whenever the page is getting redirected, that should take care. Other thing is when you have a third-party website, when you have links which are going to an altogether new website, it should be always open to the new window rather than on the same window because this will confuse the screen reader users because they cannot see what is happening. They are 100% dependent upon the screen readers. Another thing is images are tag. And nowadays emojis are taking all across the web. We developers, we get the designs from the designers, which are very jazzy with emoji icons and everything, but we forget that that emoji icon, first of all, the screen reader user won't be able to see them. So if that emoji icon do have some content which you want to relay, please provide all that for. These are the things which developers should take care of it. And if they are not getting the alt text and everything, they should think like an end user and add it. One more thing I would like to add in that list is color contrast. Though this falls in the designer plate, but when we are doing the development in Chrome and in Mozilla also, in that deep development tool, we get the information, the color is accessible or not. If it is not, then we developers should go back to our designers and tell them to give us the accessible colors. So these are the few things developers should take care of.
DAN_SHAPPIR: In the context of the last point that you mentioned, a feature that was relatively recently added to Chrome DevTools, I don't know if it also exists in Firefox. I mostly use Chrome DevTools, which I enjoy a lot, or I'm really happy that was added is actually a drop-down that enables you to enable the presentation of the site in a way that matches what users with particular visual disabilities will experience so that you can actually literally invite the relevant product person and show them, this is how the page will look for a person that has this or that particular visual impairment or disability or limitation. And I have to tell you that that definitely is something that impacts a lot of people. I myself have gotten to the point where I need to use reading glasses when I'm reading stuff from the screen. And on certain occasions, I remember one time when I actually forgot to bring my glasses with me to the office. So for that entire day, I was seeing things kind of blurry. And it definitely made my life much more difficult accessing various services from various websites. So definitely, this is something that we can relatively easily, in a straightforward way, show people. And like today, a lot of people out there have some form of visual limitation, constraint, disability, call it whatever you want. But you were talking before.
AJ_O’NEAL: It happens to everyone. Ah, yeah. Well, I want to hit on this for a second. Because I don't think many people are, especially younger people that are, I think, the majority of developers at this point are probably under 40. I think that's fair to say. As you get older, and I have not experienced this myself, but I've done a little bit of research into this. As you get older and you hear your grandparents talk about it and whatnot, or your parents maybe, or yourself maybe. Your ability to perceive the difference between light and dark becomes less and less. So you get less contrast. So when you increase contrast in color palettes, you make it easier, not just for older people to read, but for younger people to read too. The same thing with thickness of lines. It's super popular right now to do these hairline fonts that can only be read on a retina display. They can't like, or just, completely illegible on your average cheapo Windows computer. And there are tools like Adobe Cooler, which I think they now call it just Adobe Color, that will help you find color palettes that have good contrast between the colors and the palette, but are still complimentary and blend well together. And I think this is really important because I don't have any problem with my eyes, but I got a problem with my brain and it is very difficult for me to reason about things visually that don't have depth and contrast. So I find many sites today to be very difficult to read and to use. And I know that people that actually suffer from problems with their eyes have an even worse time than I do.
DAN_SHAPPIR: It's interesting what you said, because like I said, about a year ago I started using reading glasses. I think at my age it's fairly reasonable. One thing that I noticed was that not only was I seeing things more clearly, there was also greater contrast for me. So interestingly, just using these reading glasses introduced a lot of contrast into the images and the text that I was looking at that just kind of I was losing gradually over the previous years. So definitely I totally agree with everything that you said. And especially in these days, we might be thinking that maybe it's not as, you know, it might not be economically worthwhile to support people with disabilities. I would definitely disagree with that. But a lot of time it's the older people that have the money. So if you're giving up on a huge segment of the population, just because your designer wants to use the most popular layout and font, and like you said, razor thin and hardly any contrast, well, you know, prioritizing form over function is definitely going to lose you income.
NEHA_SHARMA: That's actually true. And one of, one of, one more thing I want to add here is color blindness, which a lot of people just ignore. And there's a study also that most of the disabilities are not visible. So I have seen a lot of websites where the folks present the status, represent the status with color. Now the, like form errors of form 6S. Now imagine if a person is colorblind and you are putting error out there in red color and nothing in the text, that person will not be able to understand that why that form is not getting submitted. So that is also one of the areas where I have seen a lot of websites are failing.
DAN_SHAPPIR: You mentioned before something that I was not really familiar with. So maybe you can elaborate on it unless I misunderstood. You were talking about the fact that in single page applications, rather than having page transitions like you would in multi-page applications, you have more complex transitions where the page changes in response to the user interaction. And that these kind of transitions, because they're not complete page, full page transitions, but like partial content transitions, are sometimes invisible to technologies like screen readers. And you said that there are ways to overcome this. Can you elaborate on that a bit?
NEHA_SHARMA: Generally, when you are using the multi-page application, whenever a refresh is happening, your whole browser is getting refreshed. And as a result, the screen readers are going to say aloud that this is the title and everything. But in the single-page application, this doesn't happen, no refresh. So whenever such thing is happening, we should use real life. So what it does is it actually helps us to understand whenever a notification is coming on the page. So there are two types of ARIA live. You can do a polite, and then there's another one. With the polite, it means it will wait for whatever the action the user is doing, and after that, it is going to say aloud whatever the notification came on the page. If it is not polite, it is assertive, it would be like that. It will just, at that moment, it will take that notification on priority. And then it is going to say aloud whatever the change or the notification came on the page or anything, any action happened there. So this is the most important thing yet a lot of developers miss out when they're creating the single page application.
DAN_SHAPPIR: Can you give an example of such a notification? What would such a notification say?
NEHA_SHARMA: Sure. For example, if you are adding an item on an e-commerce application, visually we get a color change or one item added kind of notification on our web page. But for the screen reader, if we haven't used ARIA Live, that one item added to your cart will never get announced. So no matter how many times they are just clicking, they will never get the response, is their item got added or not? In this case, we should use the RLive attribute where it will announce every time the item is getting added and this notification is coming, one item got added like this. So this is one of the, I would say the most of the realistic use case of this.
DAN_SHAPPIR: I understand. If you're considering the various frameworks, like React, Angular, Vue, are there like noticeable difference from your experience? Are there like noticeable differences between them? Do some frameworks have better support for accessibility or worse support, or is it kind of doesn't really make a difference?
NEHA_SHARMA: My experience come heavily from the React. And so I won't be able to answer it, but what I have seen is, now I started working on Vue, what I have seen is the both are handling the accessibility through their, by creating the awareness through their documentation is very beautiful. So that is pretty good, but I won't be able to answer this question that what are the noticeable difference between all three.
DAN_SHAPPIR: Okay. Is there anything else you want to cover or is there anything else that we should discuss?
NEHA_SHARMA: Yeah, so one of the questions also comes is that when we should start thinking about accessibility, it should be at the start of the project or at the end of the project or at the mid of the project. Whenever you ask, it doesn't matter that at what stage you are, what matters is that if you are thinking about accessibility, start implementing it. So if you are at the end or the mid, you already did the development. So what you can do is you can just run these tools and there are plugins available for your IDE also, which you can integrate. And then you can look at the bugs and fix them. In most of the cases, the bugs are not so big. They will be mostly like about fixing the semantic tags or the alt tags are missing and such kind of things it won't take time. And if you are lucky, your project is just starting, and from the day one, you can start thinking about the accessibility. In both cases, it's not going to be pretty hard. The only thing is we need to just start doing it.
DAN_SHAPPIR: I definitely, definitely agree with that. So in that case, I think we covered the topics we wanted to discuss.
If you're a front-end developer looking for remote work, then I recommend G2i a React and React Native focused hiring platform that will connect you directly with their clients that need your skill set. What makes G2I a unique hiring experience is that they spend the time marketing you to their clients of your choice. G2I is a team of engineers that technically vets you upfront. If you pass their vetting, their clients have agreed to skip their initial interview process, saving you time and energy getting your next gig. They take care of all the hard work for you so you can get focused on development. To join G2I, go to g2i.co and apply.
DAN_SHAPPIR: With that, I will push us to picks. Amy, would you like to start?
AIMEE_KNIGHT: Sure. I'm going to pick something I saw a couple weeks ago that I agree pretty strongly with in most cases. I know there's a little bit of gray area if you are building software that you kind of need to push out a feature and see if you actually have user adoption and stuff like that. But it's just a blog post, but it's pretty lengthy. And I thought, well, maybe it's not that long. I just thought the point's really good just about software should be designed, and that it's called software should be designed to last. And he's talking about minimizing dependencies and stuff like that. That's something that I've been trying to do. And it's actually been a lot more enjoyable and a lot easier than I thought it would be, especially when I need to debug things. Just the feedback cycle is so much faster when I'm using just the bare metal tools and not having to decipher library error messages and stuff like that. Oh, you might pick.
DAN_SHAPPIR: Cool. AJ, how about you?
AJ_O’NEAL: Well, I got a couple of good ones and a couple of bad ones. Wait, that's not how that goes. There's a video which fortunately has a little bit of language sprinkled in that probably won't be too offensive to most people, but maybe not something that you want to open up in front of the TV with your kids, but it's called Micro Services Parody. And I it feels like a documentary, not a parody. I have been in that room. I have that. This is a conversation that I, yeah. Yeah. It's just, don't know how to explain it, but I recommend watching the video. If you don't get it, it's because you have not worked at a company that does things that way, but that is definitely really, really common. I, I, I I'd like, I wish I could describe the video, but it wouldn't do it any justice to even try. But saying microservices parody is probably enough. So I'm going to pick Mother Earth because she gave birth to Yellowstone National Park, which turns out to be an excellent place to visit where there are some unique features that are found in few other places on the entire planet. So Yellowstone has, I think it's something like 90 plus percent of the world's geysers or maybe more than that. It's something like 200 out of 220 geysers or I don't know exactly what it is. But it's like way overrepresented. It's not, geysers are not equally distributed across the planet at all. And lots of other cool things, boiling mud pots and prismatic springs, like the bacteria that grows there in these hot springs grows by color according to the heat of the spring. And so you get rings of almost like a rainbow, but it's mats of bacteria. It's not even moss or algae. It's just like it's the weirdest thing and it's like gorgeous and beautiful. So obviously not everybody's going to have a chance to visit, but look up some of the pictures online and YouTube and stuff. And then two more quick things. Windows 10, I love hate Windows, love hate relationship, but Windows 10 has curl, it has tar, it has SSH, and it has PowerShell, which although kind of a confusing shell is worth using in comparison to command.exe. Yeah, anything's worth using compared to command.exe. As I've been working on WebInstall.dev, I've actually got help with someone who is an employee of Microsoft, who is able to explain some things and help out with some little ahas and gotchas. So we're getting better Windows support for WebInstall.dev. If you see something there that you'd like to have Windows support for, open an issue and I can prioritize it. Otherwise, we're just gonna handle things one at a time. But Node is now installable via Windows as well as some of the scripts SSH pub key that script is now working on Windows as a PowerShell script to complement the bash script. So anyway, got that. And then Kent C. Dodds, you know, he outputs a lot of good material and I really liked a recent article he had on AHA programming, which is avoid hasty abstractions. I'd actually been thinking about this myself and trying to come up with something that would be sticky and catchy. But someone else had already done it. And then he kind of summarized the difference between dry, meaning don't repeat yourself, wet, which is write everything twice, which is something I absolutely agree with. And then aha, which I think is the core principle that dry and aha need to go together, avoid hasty abstraction. So I'll give a link to that as well.
DAN_SHAPPIR: Yeah, that sounds really interesting. I want to be looking at that. By the way, Yellowstone is one of the few parks, main parks or major parks in the US that I've not visited yet. We were supposed to visit there when I was a kid and then something came up and we didn't. And it's definitely on my list of places to be and things to do. Hopefully, we'll be able to start traveling again sometime in the future and I'll be able to plan a trip over there. It's definitely a place I want to visit.
AJ_O’NEAL: Well, let us know when you do, because from our comparative point of view, a five-hour drive is not a big drive. We'll meet you up there and go around, or keep it to your own family and don't invite us. We'd go back. We'd go back. There's tons of stuff we didn't see. We were just there for a couple of days and just saw a couple of core things.
DAN_SHAPPIR: I think it's also like one of the biggest parks in the world, isn't it? Certainly in the States.
AJ_O’NEAL: Yeah, you can enter it from like four different sides and it's an hour drive across in each direction or more. It seems to be pretty big.
DAN_SHAPPIR: Cool. So Neha, I hope that, I don't know if you noticed this whole pig thing and hopefully you have something for us. If not, I'll talk ahead of you and give you a bit of time to come up with something. But do you have a pick for us or a few picks for us?
NEHA_SHARMA: I was just following what AJ was mentioning. So if it is about, you know, just, I will just giving the picks. So I will do plus one for Quancy. And also I recently started working on AWS. So for my pick is Nader. He work on in Amazon and I will just drop the handle of him. He do a lot of good content. So yeah, that's the one and any that I can think of as of now.
DAN_SHAPPIR: Cool. So I have a few picks of my own. So pick number one is that my eldest son has decided to start learning programming. It's been something that he kind of resisted doing for a long time, which was kind of interesting because he's really into maths and sciences, but for some reason wasn't into computers. So now he's giving it a go. And it's interesting for me to experience firsthand somebody who's really just entering the field and running into all the issues and problems and stuff that I had to deal with several decades ago. One thing that I notice is that one, the advice that I keep on giving him repeatedly is to try to avoid when trying to figure out a bug or a problem or why whatever software he's written is not doing the thing that he's expecting it to do, is not to try... The problem is that too many people don't understand because they're trying. They haven't in their head what they intended the software to do, and that causes them not to see what they actually wrote down, what the software actually does. So what I keep telling him to do is to just take a pen and paper and literally execute the code himself, like one line at a time, and write out the current state on a paper. And then for each instruction, just be totally literal about it and update the state based on what the instruction actually says. And when I actually made him do it he would run into situations where he would say, yeah, but that's not what I meant. And I would say, exactly. And that's the way that you, is the best way I think for beginners to kind of figure out the causes of bugs. And I think, and actually I have to say that even after all these years, I still effectively do this. The only difference being, I guess, that for some straightforward cases, I can do it in my head rather than having to do it explicitly with a pen and paper. Sometimes I cheat and I do it with a debugger. But still, running the code in your head as if you were the computer, I think, is one of the best ways to figure out why some piece of code that you've written doesn't actually work. So that would be my advice slash pick. Another pick that I have is I mentioned it before, I think. But I'd like to mention it again, like run into unexpected behavior and code that I write, I like to turn it into a riddle because I assume that if I can distill it down to a sufficiently small amount of code and I can maybe tweet it as a riddle, if it confused me, it'll probably confuse other people as well and trying to figure out the solution as a riddle is more fun. And then it's kind of enjoy, it's an enjoyable way of learning something new. So if you want to see various riddles that I've done about JavaScript, just go into Twitter and search for the hashtag JavaScript riddle as one word, obviously, and you can see quite a number of riddles that I've written down over the past few years. And interestingly, now that I've just done it, I see that there's also somebody else who's also put out a riddle or two, which is really cool. And I'll have, and I need to go out and check out the riddles that they've written as well. So I've just benefited from giving this as a pick. And those would be my picks for today. Anything else that anybody wants to add? OK, then. In that case, I think it's time to wrap up another episode of JavaScript Jabber. Oh, before we go, Neha, if people want to connect with you, if people want to reach out to you to talk about accessibility or anything else. What would be the best way to get in touch with you?
NEHA_SHARMA: They can reach to me on my Twitter. It's hello Neha, Neha with double H. That would be the perfect platform to reach me.
DAN_SHAPPIR: Excellent. So with that, I think we'll wrap up another episode. So thank you everybody for joining us. Bye.
AJ_O’NEAL: Adios.
Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. To deliver your content fast with Cashfly, visit C-A-C-H-E-F-L-Y dot com to learn more.
JSJ 444: Coding Front-end JavaScript for Accessibility with Neha Sharma
0:00
Playback Speed: