Update: thanks to inhuofficialfor the suggestion to drop the images and add code snippets.
1. How to do an accessibility audit of Mobile and Desktop websites?
Answer: Accessibility audits required manual and automated efforts. It doesn't matter which device or platform one is on. So, the approach would be:
Mobile:
Every mobile comes with inbuilt accessibility tools and we can use those to test mobile accessibility. Eg: screen readers we have Voice Over for Apple, talkback for Android, and so on.
For desktop, we have pre-installed, Free, as well as paid software for testing Such as Lighthouse, keyboard, screen readers.
2. What is ARIA? While creating a Tab module how you will decide the ARIA tags?
Answer: ARIA stands for Accessible Rich Internet Application. ARIA is useful for screenreader users. It won't create any difference visually. There are many tags, states, and properties missing from the HTML tags. Also, there are many custom modules we make such as carousels, pagination, etc which are not defined in the HTML. These are impossible for screenreader users to understand.
ARIA provides information about such modules by defining the roles, properties, and states for screenreaders.
In short, ARIA is the bridge between missing information in HTML and screenreaders.
3. What is the importance of landmarks? Can you write a code for a webpage and use landmarks in that?
Answer: Landmarks are the way to mark the areas of a webpage for the keyboard and assistive technology users (screen readers). By using landmarks we identify the organization and structure of the webpage. Landmarks should provide the same structure programmatically of the webpage as it provides visually.
4. Is the below CSS snippet accessible or not? Why?
/* Is this CSS Code is Accessible? **/
h1{
color: #fff;
font-size: 24px;
}
h1::before{
content: "Click here"
}
Answer: No, the above code is not accessible one of the issues is the content is coming from the CSS which will be not be picked by the screen readers.
5. As a senior developer how you will make sure that accessibility is getting followed?
Answer: First of all - "Accessibility is not a feature. It is a human right". I strongly believe in this. Hence, instead of setting my team's expectation that they will get the requirement from the client or product manager about accessibility, I will ask them to focus on writing the right code. As well, I will make sure that every developer is using the ESA11y plugin in their code editor, lighthouse test, and integrated with the CI pipeline.
6. Is the below is accessible?
<img alt="Header with Logo" src="backgroundHeader.png" />
No, the above code is not accessible due to the alt tag. Though I am assuming here based on the image name it is decorative image only and for screen readers this alt tag is not adding any value at all.
7. For accessibility should we use em or rem?
Answer: For accessibility, it is preferred to use rem for the margin/padding and em for the font-size. One more way we can do here is:
html{
font-size: 100%;
}
The above code snippet is going to help the users to take the font-size according to the user's setting.
8. What is VPAT?
Answer: It is a non-official document used by the products to share information about their product's accessibility level. You can read in detail here.
9. How vision disables people use mobile?
Answer: Mobile has screenreaders installed by default in them. Disable people use those to use mobile.
10. Why type is important in the input?
Answer: The HTML type attribute is important for screenreader users. The types will help them to understand what input type it is as well as the security reason associated with the password field. If the password type is missing then the screenreader will speak aloud the password user is entering.
11. What is an accessibility tree?
Answer: Just like we have the DOM similarly we have the accessibility tree. We can see this tree in the firefox and Chrome debugger too. This helps the developer to see how the accessibility elements are getting added such as role, focusable, alt tag, aria-labeldby, etc.
Questions? You can reach me at Twitter
Happy learning!!
Top comments (5)
A great post, but surely, when talking about accessibility, the one thing you should do is not use pictures of code with vague
altdescriptions. That isn't very accessible! 🤣🤣.You can add code blocks easily using triple back ticks ``` and then the language you are using (as then you get the correct syntax highlighting but you can just use ``` and not specify a language). You then close the code block with triple back ticks again like so:
``` css
/* your css code */
```
Which results in:
Also for question 6 (you forgot to answer it 😋) the answer is entirely based on the context in which it is placed. My guess would be "no" as the
altdescription is not good if this is the company logo but it is impossible to say (especially as if this is contained within a hyperlink, as is the norm with logos, then the text within thealtdescription should change to reflect the link purpose).Would I hire you based on those answers? I probably would so great answers overall 🤩
Aah!!
Alt tags I added "CSS Code snippet". (What you think should be the right alt tag? Just thinking now...how I can have better alt tags for these screenshots.)
I will update the code block syntax.
Thank you for reading and sharing your feedback. Highly appreciated. 🙏
I meant replace the images of code with the actual code itself using the technique I described. That way screen reader users can just read the code! As an added bonus if anyone ever wanted to copy paste your code they could, or if they prefer a different colour scheme they can change it etc!
Not an issue, easily missed when moving stuff, completely get it!
Look forward to seeing more from you, followed!
Post updated & Followed you too.
Thank you :)
This is a great post. Thanks for sharing it.