Basically when it comes to screen readers, they will parse content as it appears in the DOM as blocks of items to be read aloud.
This is why it's so important to use semantic HTML and truly understand how you are structuring your content.
A good rule of thumb is to not try to force a voice reader to have a certain cadence (like making multiple paragraphs into a single paragraph element so it gets read as one) or nesting anchor tags into paragraph elements because that's the way the copy appears.
When it comes to making accessible experiences it helps to use the tools that disabled people use to navigate, even better is if you had disabled engineers or people when doing user research.
What becomes a challenge is that all the assistive tech are similar to all the different browsers, they all have their own standards and how something gets read aloud in VoiceOver may not be the same as NVDA.
I'm actually creating a cheatsheet for a11y in general (at first I was tailoring it to react, but taking a general web approach now). I'm not done with it, but if you want to look on github I have the same username as I do here.
Also a good resource about a11y in general is Deque Systems. They're a consultancy that specializes in a11y, they've also created a popular tools in the OS community like axe. They put out many great talks not just about the engineering side of a11y but also the legal issues, how design is impacted, what sort of automation can be done to help find issues.
Not sure, there are some tools to help, but I'm not front end dev and haven't used them. However, you can install a screen reader and try the browsing shortcuts on your website.
Voice over is installed by default on Macs, NVDA is free and open source for Windows, and Orca is on Linux.
This is why it's so important to use semantic HTML and truly understand how you are structuring your content.
A good rule of thumb is to not try to force a voice reader to have a certain cadence (like making multiple paragraphs into a single paragraph element so it gets read as one) or nesting anchor tags into paragraph elements because that's the way the copy appears.
When it comes to making accessible experiences it helps to use the tools that disabled people use to navigate, even better is if you had disabled engineers or people when doing user research.
What becomes a challenge is that all the assistive tech are similar to all the different browsers, they all have their own standards and how something gets read aloud in VoiceOver may not be the same as NVDA.
I'm actually creating a cheatsheet for a11y in general (at first I was tailoring it to react, but taking a general web approach now). I'm not done with it, but if you want to look on github I have the same username as I do here.
Also a good resource about a11y in general is Deque Systems. They're a consultancy that specializes in a11y, they've also created a popular tools in the OS community like axe. They put out many great talks not just about the engineering side of a11y but also the legal issues, how design is impacted, what sort of automation can be done to help find issues.
https://www.deque.com/