Created on READZ
sigmund-HE1zW44Zm_Y-unsplash.jpg

Web Accessibility at Readz

What’s accessibility, you ask?
It’s the practice of creating designs and content that anyone can access, regardless of their abilities. That means — but is far from limited to — text that blind people can “read.” Audio that deaf people can “listen to.” Not using interactions and animations for those who might experience seizures.
Accessibility efforts are guided by the modern definition of “disability”: a mismatch between an individual and their environment.
Accessibility is the practice of reducing the number and intensity of mismatches between the environments we create and the individuals who live and work in them.
Accessibility isn’t just a legal requirement. It’s a way to expand your audience and improve the end user experience for everyone.
Our commitment to accessibility
At Readz, we take great pride in providing a platform that empowers organizations to easily create content experiences that look great on any device. What’s just as important, however, is making that content accessible to anyone by following the Web Content Accessibility Guidelines (WCAG) and by taking these guidelines into consideration with every new feature we launch.
With WCAG’s latest version (2.1) being published in June 2018, these guidelines have evolved since their inception and are now adopted and recognized internationally. As a result, other government policies related to accessibility have come into effect as well, such as the Americans with Disabilities Act (ADA) and Section 508 of the Rehabilitation Act (508) in the United States, and the Web and Mobile Accessibility Directive in the European Union. These are based on (or refer to) the WCAG.
Accessibility guidelines like WCAG live at the very core of our platform
Readz projects or web publications are built with standard programming languages that were developed with accessibility in mind (e.g., HTML5 and CSS). Our visual design studio enables designers to make content that anyone can experience. We make it (relatively) simple to publish screen-reader-friendly text, add alt text to images, provide sufficient color contrast, and create keyboard-friendly web pages. Additionally, we provide the capabilities for our users to implement best practices such as headings to indicate the hierarchy of texts, we use responsive image technology to ensure sites load fast and make SEO-friendliness a central part of the offering. And have a lot more coming...
How we made Readz projects more accessible
  • By building our internal expertise around accessibility. We’ve brought a subject-matter expert onto the team, to help us build accessibility best practices into all our development processes. And we started enrolling our design and production team in accessibility training.
  • We are incorporating accessibility into our design, development, and QA practices. Like most web development disciplines — be it SEO, content, or UX — accessibility works best when it’s baked into every step of the process. It’s far easier to build a project with accessibility in mind than it is to hack in accessibility late in development. Find more info about How to Design for Accessibility.
How designers can build accessible content in Readz
Create Hierarchy
For those without vision impairment, it’s easy to understand the hierarchy of visual content, thanks to a range of visual cues. However, these cues don’t translate for those using screen readers. To solve this problem, designers can communicate hierarchy through non-visual means, using tools like Header Tags (H1, H2,... ) Paragraph tags and Landmarks. Screen readers and keyboard navigators traverse these page elements, so it’s important to establish order. These descriptions can be added by dragging and dropping pre tagged elements directly from our UI, so it’s fast and easier to tell which tag best describes your element or section.
More info on Semantic markup is used to designate headings (<h1>), emphasized or special text. (<strong>, <code>, <abbr>, <blockquote>, for example), etc.
Tables are used for tabular data and data cells are associated with their headers. Data table captions, if present, are associated with data tables.
Frames and iframes are appropriately titled.
Improved keyboard accessibility
Keyboard accessibility is one of the most important aspects of web accessibility. People with visual or physical disabilities often rely on their keyboard to navigate through websites. In most cases, this involves using the Tab key to jump from one interactive element to the next (e.g. text links, buttons, form fields, etc.).

We’ve launched several improvements in this area. When using the Tab key to navigate through a publication, a visual indicator will highlight any link or “keyboard focus” elements.
Contrast Ratios and style sheets
The definition of contrast ratio between the link and the surrounding text can be set to at least 3:1 and an additional distinction can be provided when the link is tabbed or hovered over and receives focus.
  • 1.4.3 Contrast (Minimum) (Level AA)
  • Text and images of text have a contrast ratio of at least 4.5:1.
  • Large text - at least 18 point (typically 24px) or 14 point (typically 18.66px) and bold - has a contrast ratio of at least 3:1.
More prominent alt attribute fields for images
Adding alternative text for images is the first principle of web accessibility. It is also one of the most difficult to properly implement. All images and image map hotspots have appropriate, equivalent alternative text. Image alternative text is present, within the alt attribute of the image element.
Making the alt attribute field more prominent in image settings, adding it to the asset manager, and defaulting it to generating empty alt attributes, the best solution for merely decorative images.
Images that do not convey content, are decorative or contain content that is already conveyed in the text can be given null alt text (alt="").
Accessible prebuilt layouts
And one of our latest features -prebuilt layouts and design blocks- was built to be accessible out of the box, and adhere to accessibility best practices like heading hierarchy, page structure, and keyboard navigatibility.
Tips for designers creating accessible projects on Readz
Creating accessible web content is not purely technical. Most of the work actually lies in making your content accessible. Here are a few practical tips you should keep in mind:
  1. Use headings correctly to organize the structure of your content.
  2. Include proper alt text for images.
  3. Give your links unique and descriptive names.
  4. Provide text alternatives for audio and video content.
  5. Design your forms for accessibility.
  6. Reduce Motion and animations
    • Motion can help tell a story, but too much movement can be overwhelming for those with visual sensitivity. If you give the audience the option to reduce motion on the page, it allows everyone to experience the webpage in the best way for them.
Do you want to learn more about creating accessible projects? Please read our extensive Help Center article: This article covers the tips above in detail and also lists other things you should keep in mind.
Additional resources to learn about accessibility:
  • Microsoft Inclusive Design
  • Heydon Pickering’s Inclusive Components
  • WebAIM
  • The World Wide Web Consortium’s Introduction to Web Accessibility course
  • Web Content Accessibility Guidelines (WCAG) Quick Reference
  • The A to Z of UX — A is for Accessibility: 12 tips for designing an inclusive user experience
On the roadmap, in case the design requires forms and buttons
  • A more accessible alternative to background images
    • Adding supported CSS properties, giving people a more accessible alternative to background images, which don’t support alt attributes.
  • Embedded multimedia is identified via accessible text.
  • Form buttons can have a descriptive value.
  • Form inputs can have associated text labels.
  • Equivalent alternatives to complex images are provided in context or on a separate linked page.
  • Blocks of text over one sentence in length