Skip to content

Hackday #9

Jump to bottom
Andreas Moesch edited this page Nov 30, 2018 · 9 revisions

29.11.2018, at the office of “Access for All” in Zurich

Table of Contents

Participants

  • Sylvia Winkelmann + Reto Inniger + Andreas Uebelbacher, Access4All
  • Markus Graf, ZHAW, Accessibility Doctor
  • Annika de Maeyer, Schweizerischer Gehörlosenbund
  • Andreas Moesch + René Stalder, Nothing AG
  • Esther Brunner, Zeix
  • Lea Marmet, Communication, private
  • Donato Rotunno, Liip
  • Graciela Schütz + Christian + Manuel + Oriol, Unic
  • Jürgen Rudiger, Hinderling Volkart

Perspective from Schweizerischer Gehörlosenbund

  • For people who use sign language as their primary language the written text on a website can be more challenging. It’s not their native language even though they have no problem perceiving it. —> “Simple language” can be of value there
  • Sub titles in movies can definitely help but for important information a sign-language translation is valuable. Should be done by a native signer. – Creating sub titles for movies is actually quite easy.
  • WCAG reserves level AAA for sign language translations. They are somewhat skeptical of that. Instead of using compliance labels it would be better to first focus on what is doable in a given project and then decide.

Which content is also important?

  • Sign language for important content + page on sign language
  • How to create sub titles for a movie with free tools
  • Plain language / simple language
  • Not only for developer, also strategic, content, and design aspects
  • Topics that Access for All mentions in their report should generally also be available in the Guide (example: “Sprunglinks” was something that came up in a report but can’t be found on the ADG currently)

Publishing Workflow: How to involve Access for All

  • Flags to mark pages to be reviewed by Access4All: content / widget
  • Before a new release all new or changed content pages need to be reviewed by Access4All
  • Before a new release all new or changed widgets need to be retested by Access4All
  • Developer push Access4All, when new content / widgets are ready for review
  • We aim to release more often, about every 3 months
  • For now we plan which content we want to have in which release. Deadlines create pressure which can be productive in the current situation. After a couple releases when the “production” has stabilised a bit we might be able to switch to a more open model: where release dates are given and content is added to the release when it’s ready.

Pull Requests

Mobile screen readers #172: owner Reto Inniger

  • Being evaluated currently at Access4All
  • Fragmentation of Android is a challenge. E.g. there is not even a consistent way to just launch TalkBack.
  • Decision: We have to focus. Either consult market data to see which distributions of Android are the most common and then document those, or focus in vanilla Android exclusively. In any case this will need a clear disclamer.

Colours & contrast #152: owner Andreas Moesch

  • Josh is the author but not in the project anymore, which leaves Andreas M as reviewer in a special position.
  • Decision: Andreas M takes ownership of the content, applies his review and submits it to Access4All

Add Single-page application optimisation to examples #173: owner René Stalder

  • There was a discussion about whether or not this should be added to the Guide. There were doubts about relying too heavily on external resources. They have to be checked, can fall out of date or vanish.
  • It’s possible to include a link checker in the build process or to simply rely on the community to report broken links. This is also part of being open-source.
  • Decision:
    • René continues to work on this and submits a first version to Access4All for review
    • Section should be moved to knowledge
    • Access4All will evaluate this topic from their perspective during their review.

HTML Boilerplate #174: owner Markus Graf

  • Has been iterated after the last hackday.
  • Soon to be submitted to Access4All for review.

Release Date for 1.1

  • Pull Requests should be finished till next Hackday in January
  • Testing by Access4All by end of February
  • Release in March
  • Lea Marmet and Esther Brunner coordinate for communication of the new release

Who organizes Hackday #10?

  • Donato Rotunno, Liip, in Berne, will setup a Doodle / Slack

Fundraising

Sylvia Winkelmann needs information to address potential donor organisations:

  • core team: who is behind this initiative?
  • amount of work: on side of agencys and Access4All
  • impact: analytics, conference talks

Who has access to the Netlifly account?

  • Originally from Unic but it would be good to have this available in the project team
  • To Do Reto: Get ahold of the login credentials and start building a centralised place where the credentials for such important accounts are stored

Testing/Usability

Nothing did testings with three developers, two more should be added. Presentation of preliminary findings and interesting points. No concrete solution proposals.

  • The guide assumes a certain base knowledge about accessibility. There is no concise introduction on this page that tells someone who has never heard of the concept about what accessibility actually is (something like on https://www.w3.org/WAI/fundamentals/accessibility-intro/#what)
  • People don’t automatically trust this source: Currently the credibility is mostly built on the names of the agencies and “Access for All” as a foundation. But someone who’s not familiar with the Swiss-German IT scene won’t know what these logos mean.
  • Is it a reference or is it a book? For practicality reasons the testing focused primarily on scenarios where people have to use the website to find information, using the ADG more like a reference. At the same time the guide wasn’t conceived as this kind of format; its ambition is to be a source where people can build up knowledge, something that they can read through, something that gives them the full picture.
    • The question is whether that actually meets the needs of our audience (frontend developers at the moment).
    • You can’t fully do both, they require different design decisions. Right now, the guide is not a particularly good reference for people with very specific information needs in a specific situation.
      • Search is quite hidden.
      • Information architecture is not very transparent: Naming of links in the Navigation can be cryptic, distribution of information in “Knowledge” or “Examples” can seem arbitrary. It’s often not obvious where to find information if you only browse.
      • Rather verbose: content is hard to parse, a lot of prose
    • Discussion
      • Short-term fixes (aiming for a point release, incremental):
        • Allow for longer labels in the navigation so that they can be a bit more verbose,
        • Improve the start page: Add some links to important parts of the Guide: e.g. something about accessibility in general or something about the team behind it.
      • Longer conceptual work (aiming for a redesign, a major release)
        • Sharpen the picture of who this guide is for and how they would use it. Define goals
        • Liip and Unic could take a look at the content structure. They have specialised people in-house who do this all day
        • Offer a more task/scenario-based entry to the content: e.g. “How to create an accessible auto complete”, “How to…”
        • Split more consistently between example code (specific problem) and background knowhow (the full picture). Like this we might also address particular needs more effectively.
  • Background effect when scrolling down keeps being controversial: We only tested with three people but even there one person said that she disliked it (aesthetically and also usability-wise irritating).
    • Discussion: Why is it there? What value does it add? Is it worth it?
  • Misalignment between links in navigation and page titles: It wasn’t obvious for the testers that the links in the navigation and the prev/next links at the end of a page would like to the same pages. Same for the teaser tiles on a section overview page.
  • The linear page content order is accessible and robust but not very convenient for deeper analysis: E.g. on the Bad examples page for headings there is a code example, then a bunch of screen shots and further down a list of issues. They all reference each other but can’t really be read and seen in union. It requires a lot of scrolling.
    • At the same time it’s important to keep in mind that the guide should also comply with accessibility standards, it has to be accessible itself. So, creating complex non-linear interactive architectures might be a challenge.

Open issues for release 1.1 (besides pull requests that were discussed earlier)

iOS bug

  • On VoiceOver on iOS the site is not behaving very well
  • Assigned to Jürgen

Content Structured bookmarklet

  • Bookmarklet is implemented as a link in Markdown but it doesn’t compile as a link
  • It’s a build issue.
  • Easy solution: Link to another page outside of ADG.
  • Can the interpreter handle raw HTML? We could just write an tag instead of Markdown
  • Assigned to Renato

404 page

  • Assigned to Jürgen

Analytics

  • To Do: Figure out what we have in the Netlify access logs, whether there are access logs at all
  • If we need more information we can install Matomo.
    • Nothing could provide this service, hosted in Switzerland.
    • Would require changes on the Serve Setup.
  • Reto checks the Netlify information

Add date to entries

  • When was a page last updated? We already have the information in Github but we want to make it transparent: Articles without a date, especially in a technical domain, can be untrustworthy or at least put in question.
  • Decision: For a start just add a date
  • Is it always necessary? Could people disregard valid information because of the date? —> Let them decide.
  • Assigned to René

Search display

  • Search is not fully accessible for the interaction. Might need another issue.
  • Assigned to Donato

Responsive examples

Provide screen reader shortcut cheatsheet

  • Assigned to Graziella

Reminder: Git publishing/review flow

  • Everything that is new or improved goes into the release branch for 1.1 (doesn’t make sense to do this even for minor typo fixes or urgent usability fixes. No clear policy there)
  • All pull requests will be done against the release branch, not master.
  • Work in progress tasks will have a “[WIP]” in the name
  • When it’s ready for review the “[WIP]” will be removed and it will be assigned to a reviewer
  • After that internal review it will go to Access for All for a final review
Clone this wiki locally