Session 3: Web-based "screen reader"

- | #webreader | Accessibility Club Meetup #8

Session notes

  • Author: Sebastian Greger

    Topic for discussion:

    • A client is enthusiastic about a11y

    • wants people to be able to go to website and listen what is on there

    • question:

      1. is it a good idea? does it interfere with screenreaders? do i need to talk customer out of it? 2a. if yes, how can this solution be implemented? 2b. if no, how to talk him out of it without discouraging his enthusiasm for a11y

    "Insieme": icons that also read what the menu points say

    same problem as with "make font bigger" buttons on website:

    • users who need assistive tech have that readily installed
    • it is often a source of dispute whether these buttons make sense regardless or not

    what is the effort to implement a screen reader in the browser?

    • ready-made plugins
    • rather easy to implement

    benefit of offering such tool:

    • there are a lot of people who don't have the expertise to set up their device with global accessibility solutions
    • advantage of offering it within the site: user who cannot install their own screenreader gets the benefit
    • embedded screenreader as a "gateway/entrypath to assistive tech"

    to engage in this debate, we also have to define what do we mean by "disability"?

    • many persons are not completely blind, but can be minor - the assistive solution helps them

    websites often represent languages with flags:

    • on a site in portuguese, i am also "blind" - flag helps
    • sites do that for languages, so you could presumably provide something like that for other things as well
    • question to be asked: is there a common design language for changing the language? even just trying to go into accessibility settings of a device is a much higher threshold than pressing a "read aloud" button --> there could be a use case for a separate page on a website to help with basic a11y features, then direct the user to make more advanced global settings on OS level example: using google in germany: initially shows results in german --> sidebar offers "see results in english" --> direct solution (a very similar problem)

    why is it that websites always offer to "make text bigger"? why not turn it around:

    • perhaps if a page with small text showed a box with large text that said "see in larger text" ?

    how to give boss a response without disenfranchising from a11y

    • just telling arguments against a detail must not discourage from a11y at large
    • it's all about how it is presented

    a little audio button could lower the access to accessibility features, it could just read the contents of the page, instead of reading the navigation etc.

    • no need for user to learn the complete navigation with a full-grown screen reader

    "in order to press the button, you need to see the button" --> make the feature visible

    design question: is it embedded where the content is, or is it detached?

    what is the clients motivation to ask for such feature? --> could it be an idea to make research, whether it is worth doing it sound like the client just saw something cool on some site, now wants it - no point in having a feature that is not being used

    important consideration:

    • how about the process?
    • who is going to ensure that this keeps working in the future as the site is developed further, potentially by somebody else?

    visual impairment is a spectrum, from fully sighted all the way to blind. by a little bit of work, we can help a certain chunk of people to get to their goals easier? just allowing to change font size can help a lot of people (bigger buttons); maybe that is the better investment than teaching them to learn an entire new tool?

    three levels of WCAG guidelines: A AA AAA - font sizes, contrasts, etc.

    some current design trends:

    • "mobile first"-thinking motivates to design with bigger items (e.g. minimum 18px of text)
    • tell clients to make text shorter
    • general rule for thumb targets: 60px
    • internationally applicable standards may vary (e.g. optimal chinese script font size might be different from western script)
    • tools, e.g. sketch plugins, help assessing a11y


    • if we rely on user research, we may miss users that have accessibility needs
    • those who need these tools the most are often very small groups of the population

    analogy: museum

    • you can visit and enjoy without audio guide
    • it adds another level of experience to use an audio guide, even as a sighted person

    user research:

    • challenge of recruiting users to test a11y features
    • specialised consultancies can help
    • NGOs specialised in certain impairments are good sources of assistance

    screen readers on mobile vs. on the web:

    • very difficult on mobile
    • when opening the eyes while testing, it interferes with the test (e.g. in QA)

    what screenreader to use for testing/research?

    • NVDA screenreader might have a free version for testing
    • other free/open-source solutions?


    • when having a in-site screenreader, it sends the message "we are accessible":

    from "mobile-first" to "accessible-first"?

    • is this a technique people have experience with?
    • Accessible/accessibility first design articles:
    • discussion: is that similar to the concept of "universal design"? including all people.
    • designing for as many people as possible, incl. those who don't have fancy smartphones or fast connectivity

    some design techniques:

    • start with black & white design, is it understandable without color?
    • make a heuristic evaluation: test early stage concepts designs with specific special needs user groups in mind (how would this design work for a colour-blind person, for a person suffering from motion-sickness, etc.)
    • UK government has a github repo with a list of disabilities (ref?)

    why don't sites start out with large type by default and offer "tighter" more "compact" view as an option

    • too few words fit on a line
    • too few words even fit on a screen on mobile
    • clients want everything in the viewport
    • sticky sidebar can interfere with folks who have motion sickness; it is also possible to deliver different experiences based on users' browser settings; e.g. users can set their browsers to ask websites for a "reduced motion" version (e.g. disable sticky elements, animations etc.)

    idea: a landing page offering alternative designs on arrival?

  • Author: Timo Motte

    GOV.UK posters for self-printing: