Test for a11y

[yuchi]

(a11y means ‘Accessibility’)

[GianBe]

Just to keep some notes on what I'm considering:

• a11y: the delay option could be useful
• react-a11y: can test react application for accessibility, it's a work in progress but could be a good starting point

These are packages that will be available in the JSON file of the project and can be used by other developers.

I did install the chrome accessibility developer tools for local testing and I'm considering the installation of a screen reader like ChromeVox

[yuchi]

Having automated tests for a11y would be awesome.

Please, make a list of devices and screen readers you intend to test on.

[GianBe]

Right now I'm trying to make it work on my pc using chrome and the ChromeVox extension (as my screen reader) and as a mobile device I borrowed an iphone, but I have some trouble with the dropdowns.

I notice that different screen-readers behave a little differently from one another for example the ChromeVox extension reads the token as a whole while the iphone reads one element of the token at a time (I think that is a problem with the chrome extension but I don't have the information I need to be sure).

I'm trying to use react-a11y and I have to say that it gives useful advice I think at some point it could be added to the project JSON.

[yuchi]

Nest steps:

• Choose the targeted platforms and a11y tools (iOS without physical jeyboard, iOS with physical keyboard, Jaws…)
• Benchmark other implementations to understand and define the desired behavior (better if native)
• Implement and test 😄
• Define a path for a11y support on non tested devices (what to expect)

[GianBe]

Traget platforms and tools:

• iOS without physical keyboard
• iOS with physical keyboard
• Windows with Narrator
• Windows with JAWS
• Google Chrome with ChromeVox

[GianBe]

I'm sorry I didn't update you on the status of the work, in this branch you will find my attempt to add accessibility.
A little recap of the work:

• I added the concept of a unique id to let some of the wai-aria properties work (such as aria-labelledby)

• As of commit 939f090 the component is compatible with:

  • NVDA
  • chromeVox

  but they can't detect the addition and deletion of tokens

[GianBe]

Just tested with JAWS.

I found something strange, Firefox + JAWS works as intended while Chrome + JAWS doesn't properly work.

Edit: Chrome is not fully supported by JAWS, the component in Firefox works with JAWS

[GianBe]

A little update on an experimental accessibility support for addition and deletion of token:
The idea was to add an hidden div element with the attribute aria-live="true" that adds a p element with the added token information inside to report the change, but I have a problem none of the screen readers that I have read the change.

In my code I tried adding in the render method of FacetedTokenInput:

...

  { /* the following div needs to be hidden if this code is going into the master branch */ }
  <div id="a11ysupport" aria-live="polite" aria-relevant="additions" aria-atomic="true">

    { /* simply add all the tokens that exist in the input */ }
    { tokens.map(this.a11ySupport, this) }

  </div>

...

and I added this method:

// this should add a node that should be detected by aria-live="true"
  a11ySupport(token, index) {
    const { facet, description } = this.props.renderToken(token);

    return (
      <p key={ "test" + index }>
        { facet }
        { ' ' }
        { description }
        { ' ' }
      </p>
    )
  }

Since I was trying to mimic the behaviour of gmail I looked at its code and google uses a similar method in fact when you add a contact to your email and create a "token" this div gets updated with some text:

NOTE: the text inside the div is in italian

<div aria-live="polite" aria-atomic="true" style="position: absolute; top: -1000px; height: 1px; overflow: hidden;"> 

{ here they add what is written before the @ or the name in your contact list } aggiunto. 
Premi backspace per rimuovere il destinatario.

</div>

[GianBe]

Some useful documentation on the argument:

General WAI-ARIA stuff:

-periodic table of aria roles: this is a comprehensive list of all the possible aria 1.0 roles

• accessibility documentation in MDN: since Firefox is the best browser (an the most used one) accessibility whise, their documentation is easy to understand
• w3c wai-aria: the current standard for WAI-ARIA
• The Paciello group's blog: everithing thats written here is good to expand the knowledge about accessibility

Examples can be found here.

aria-live in particular:

• aria-live w3c: aria-live standard
• aria-live regions MDN: basic aria-live functionality
• Article by the Paciello Group about aria-live

Examples of live regions:

• aria-live
• with aria-atomic

In the set there isn't an example of the alert role, this particular role has an implicit aria-live="assertive" built in.

[yuchi]

Do we have a compatibility table for aria-live?

[GianBe]

Browser compatibility:

• osx: Firefox 3.6 (C)
• osx: Opera 11.0 (C)
• osx: Safari 5.0 (C)
• win: Firefox 3.6 (C)
• win: Internet Explorer 8.0 (C)
• win: Opera 11.0 (C)
• win: Safari 5.0 (C)

Screen readers compatibility:

• JAWS: Firefox + IE
• NVDA: Firefox
• VoiceOver: Safari 9

[GianBe]

Reopen for test