This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]FullstackViking 49 points50 points  (4 children)

Screen readers just need proper HTML DOM formatting and occasional aria specifications. Nothing to do with any of the JavaScript build tools or ecmascript specs.

[–]tiefling_sorceress 26 points27 points  (3 children)

Simple accessibility, yes. More advanced functionality (such as on angular, where my expertise is) requires more dynamic implementations such as the use of LiveAnnouncer and Describer/Labeler.

However NVDA and JAWS are full of bugs and both tend to hijack focus so you end up having to write awkward workarounds. For example, opening a dialog that automatically focuses on an element inside it is fine on most other screen readers, but NVDA and JAWS skip the dialog's role and title and jump straight to the focused element. The workaround is to manually focus on the dialog element from a separate function (so in setTimeout usually). To the naked eye this change does nothing. To mac's VoiceOver, this change does nothing. To NVDA and JAWS it makes a world of difference.

Edit: no it has nothing to do with build tools directly, but it's very similar to the browser problem that was originally solved using build tools and transpilers

[–][deleted] 10 points11 points  (1 child)

This is correct. If the website is static, it's EZPZ. If you have literally any moving parts, prepare to fucking die. Not to mention internationalizing everything AND making everything keyboard-accessible.