![]() ![]() If your rich text editor has collaborative editing the content of a users document can change at the same time as you’re editing it. Think twice about whether you need collaborative editing Reach.ui, material ui and chakra are all react libraries that have decent accessibility defaults. Using established component libraries will give you a leg-up on reaching a good accessibility baseline. I recommend running your linter automatically (either as part of your CI or with a git hook). I cannot overstate how valuable this is especially for teams. ![]() ![]() To make it easier to stay on top of your apps accessibility, a linter can go a long way.įor react users, the a11y-jsx eslint plugin will make you aware of what attributes you’re missing to make your web-app accessible. These icons don’t have textual meaning on their own, hence we need to tell the screen reader what they are by assigning the aria-label attribute like so: Most rich text editors make use of common icons for text formatting and layout. However, for user submitted content it is too difficult to generate meaningful alt text automatically, that’s why you should consider making the alt attribute configurable by the user. If you’re rendering images in your editor, it is recommended you use an alt attribute to represent what the image contains to a screen reader. Use alt text for your images and make them configurable If you’re building an editor with a floating toolbar (such as medium - which is completely inaccessible via tab keys btw) pay close attention to how a keyboard-only user can navigate to and from these buttons and toolbar components.įor complex usecases (if you have submenus or button groups) you should consider programmatically moving focus, more info on this here 4. This will depend on the position of the element in the DOM and how many other interactive elements are in between. If you’re using an element that isn’t considered interactive (such as a div) you are required to add a tabindex and a role attribute so that the screen reader knows how to interact with the element.Ĭonsider how much work it is for a keyboard-only user (the mouse is mostly useless for a user with sight-issues) to navigate to these UI elements. DOM elements such as button, input, select or textarea are focusable by default. To ensure that elements are reachable via keyboard they need to be focusable. Most rich text editing applications make use of menus and toolbars, dynamically positioned or fixed in place. All interactive elements must be reachable via tab and/or arrow keys If you are implementing such features, check they don’t collide with hotkeys that are already in use for the browsers or operating systems. It is frustrating and hard to overcome if default keyboard functionality is prevented by an application. However, screen-reader users rely entirely on the keyboard to navigate your app, their browser and operating system. Overriding default keyboard behaviour to implement features such as hotkeys or indenting text via tab is a common pattern seen in web-based rich-text editors and IDEs. Another popular screen reader is JAWS (not free).Īll of the below recommendations become more obvious if you put yourself into your users shoes.For Windows users there’s nvda (free) which is also the most widely used.On OSX you already have one built in to your operating system: VoiceOver.I’d consider this blog-post a success even if you don’t come back to finish reading it. If you have never used a screen reader, try one out on your app or any app with that has a rich text editor. Although most points will be applicable to any kind of library you use, some of them are specific to react.js. The following is a list of 10 recommendations for building accessible rich text editors. If you’re building an app that features a rich text editor - you should make it as accessible as possible for screen-readers. ☀ 10 tips for building accessible rich text editors ![]()
0 Comments
Leave a Reply. |