Love this breakdown. Can you possibly compile most common solutions to implement as well for a follow up article? Just interested myself. Docs are all over for different stuff but someone that is more familiar with A11y may have a better process of what works and what doesn’t.
Hi. To be fair I'm not an expert myself (sorry if I made an impression like I am). I am, as you are, interested in the subject. I guess next article can list all types of disabilities in more details, for example like here download.microsoft.com/download/0/...
Having a list of disabilities we can derive list of features required by users, like better contrast, bigger fonts, alts on images etc.
Also we can derive a list assistive technologies that people use, like screen readers, magnifiers, etc. We can use those technologies to do tests, like we use different browsers for cross-browser testing.
If you are looking for quick wins, I guess, this is a good start a11yproject.com/checklist/
Very much appreciated. I think I might have to do some research on different technologies used like screen readers and write how we can develop better using knowledge of those technologies.
Kicking it in Dayton, Ohio as a software engineer with a passion for learning and teaching #a11y. Other passions include frontend web dev, drawing, running, and anime.
I would recommend reading the WCAG standards to get a comprehensive understanding. I would check them out through WebAim, which also has reference to ATAG and WAI-ARIA. Most legal guidelines have their basis on WCAG 2.0 + 2.1.
The first step to making an accessible Web app is to write Semantic HTML.
Then also finding Tools that will help you. There are dev tool extensions like Lighthouse and AXE that will also help make your web app more accessible, without having extensive knowledge on accessibility.
And understanding that DOM order is the reading order/ tab order so moving elements around with CSS may not be the best of ideas.
But then I tested it with screen reader and result was ... not so good. So I would say that semantic HTML and WAI-ARIA != accessible. Actually testing with real assistive technology - this is what matters.
Kicking it in Dayton, Ohio as a software engineer with a passion for learning and teaching #a11y. Other passions include frontend web dev, drawing, running, and anime.
I pulled your code. It's not too off from being a good example of aria for screen readers. It reads fairly well for your actionable items. it is a little buggy on initial loading, but It's reading fairly well on the screen reader I'm using. So I guess I'm curious what issues you are seeing?
I don't remember - it was long time ago. Which screen reader did you use? I guess, I used built in Mac OS assistive technology (but maybe something else)
Kicking it in Dayton, Ohio as a software engineer with a passion for learning and teaching #a11y. Other passions include frontend web dev, drawing, running, and anime.
The best documentation for fixing accessibility problems on the web is the WCAG (Web Content Accessibility Guidelines), specifically the 2.1 docs. Like you've noticed though, they can be a little difficult to comprehend for someone who is just starting to understand this field. I've tried to break down some of the more common problems with a top 10 list which should help you understand and fix them.
While a lot of the focus for web accessibility focuses on vision problems, like colour contrast, and screen readers, there's a whole lot more to it. So, for example:
A person with fine motor control issues (e.g. someone suffering from Parkinsons or Motor Neuron Disease) might have perfect eyesight, but be completely unable to use a mouse. Ensuring all core functionality is available via a keyboard would help them.
Someone who is deaf in one ear might struggle if speech audio is only available in one earphone (I've seen this happen before first hand). By adding captions, and ensuring that the audio is provided in stereo, you ensure these people can use your creation.
A person with a cognitive disorder might struggle with long, complicated blocks of text on a page. By shortening lines (both by word count and visually in width on the page) you make the text more easily read. You can also run your content through a Flesch/Kinkaid test which will gauge the complexity of the content.
With almost all improvements made to fix issues for people with disabilities, everyone else will also benefit in small ways. This effect is called the drop curb or curb cut effect. It's commonly seen with things like:
Captions - kids making noise while the TV is on, or forgot your headphones on the bus? Captions allow you to watch that latest episode without waiting until later.
Good colour contrast - besides benefitting those with colour or contrast loss vision issues, good contrast also benefits those in more exreme lighting conditions, like very high or low ambient light environments.
Keyboard access - ever tried to fill in a lengthy form using a mouse to move to each input field? It's a slow process, and far easier to tab across to each one. Good keyboard access and tabbing order makes forms easier for everyone.
Lastly, it's important to remember that disabilities are not on/off switches, and each person has a unique blend of permanent and temporary problems that can change day to day. Any fixes should attempt to take into consideration how well they will function against other problems.
It's a lot of work, but start at the beginning and make accessibility part of your development workflow. Eventually it becomes second nature in the same way that you might avoid using functionality XYZ because you know it doesn't work well on browser ABC. Things change over time, so it always helps to read up blog posts and articles where people cover various topics.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Love this breakdown. Can you possibly compile most common solutions to implement as well for a follow up article? Just interested myself. Docs are all over for different stuff but someone that is more familiar with A11y may have a better process of what works and what doesn’t.
Hi. To be fair I'm not an expert myself (sorry if I made an impression like I am). I am, as you are, interested in the subject. I guess next article can list all types of disabilities in more details, for example like here download.microsoft.com/download/0/...
Having a list of disabilities we can derive list of features required by users, like better contrast, bigger fonts, alts on images etc.
Also we can derive a list assistive technologies that people use, like screen readers, magnifiers, etc. We can use those technologies to do tests, like we use different browsers for cross-browser testing.
If you are looking for quick wins, I guess, this is a good start a11yproject.com/checklist/
Very much appreciated. I think I might have to do some research on different technologies used like screen readers and write how we can develop better using knowledge of those technologies.
I would recommend reading the WCAG standards to get a comprehensive understanding. I would check them out through WebAim, which also has reference to ATAG and WAI-ARIA. Most legal guidelines have their basis on WCAG 2.0 + 2.1.
The first step to making an accessible Web app is to write Semantic HTML.
Then also finding Tools that will help you. There are dev tool extensions like Lighthouse and AXE that will also help make your web app more accessible, without having extensive knowledge on accessibility.
And understanding that DOM order is the reading order/ tab order so moving elements around with CSS may not be the best of ideas.
I tried to follow WAI-ARIA recommendations (including semantic HTML) and used Lighthouse. Example is here dev.to/stereobooster/accessible-re...
But then I tested it with screen reader and result was ... not so good. So I would say that semantic HTML and WAI-ARIA != accessible. Actually testing with real assistive technology - this is what matters.
I pulled your code. It's not too off from being a good example of aria for screen readers. It reads fairly well for your actionable items. it is a little buggy on initial loading, but It's reading fairly well on the screen reader I'm using. So I guess I'm curious what issues you are seeing?
I don't remember - it was long time ago. Which screen reader did you use? I guess, I used built in Mac OS assistive technology (but maybe something else)
I’m using Chrome vox. I’ll have to try it out with the OS assistant on Mac.
The best documentation for fixing accessibility problems on the web is the WCAG (Web Content Accessibility Guidelines), specifically the 2.1 docs. Like you've noticed though, they can be a little difficult to comprehend for someone who is just starting to understand this field. I've tried to break down some of the more common problems with a top 10 list which should help you understand and fix them.
While a lot of the focus for web accessibility focuses on vision problems, like colour contrast, and screen readers, there's a whole lot more to it. So, for example:
With almost all improvements made to fix issues for people with disabilities, everyone else will also benefit in small ways. This effect is called the drop curb or curb cut effect. It's commonly seen with things like:
Lastly, it's important to remember that disabilities are not on/off switches, and each person has a unique blend of permanent and temporary problems that can change day to day. Any fixes should attempt to take into consideration how well they will function against other problems.
It's a lot of work, but start at the beginning and make accessibility part of your development workflow. Eventually it becomes second nature in the same way that you might avoid using functionality XYZ because you know it doesn't work well on browser ABC. Things change over time, so it always helps to read up blog posts and articles where people cover various topics.