Developer Space/Components

From wiki.gpii
Revision as of 20:26, 20 February 2018 by Till (talk | contribs) (Further edits according to steve)
Jump to: navigation, search

Executive Summary

This document contains an accompanying user guide and developer documentation for the GPII Developer Space Component Repository, which is online as part of the GPII Developer Space at. If you are interested in contributing, visit the site directly at and refer directly to the relevant section in this document.

We constantly extend this repository with new components. The repository allows structured search in a comprehensive list of building blocks for Assistive Technology development and implementation. The repository is as inclusive as possible, addressing different needs and solutions by holding a diverse set of software and hardware. The components listed on this page fulfil some minimal requirements for documentation and categorisation that we define in this document. If you want to add a component to the list please go to, drop a mail on or post to our twitter account at

The goal of this public deliverable of the Prosperity4All Project is to provide particularly technical documentation about the background of the site and the curation process, which aims to be transparent, sustainable and scalable. The document is the last one in a range of documents (D202.1 and D202.2) where we have described, how we created and designed this repository and looked at technical convergence of components through standards and APIs. If you want more detailed information about the underlying architecture of the whole Developer Space refer to D201.5 as this document documents particularly the component listing. Additionally, you should visit and browse the actual main deliverable of the project, which is online at

Background and Related Efforts

The component repository is not a unique effort in the sense that it collects accessibility related components. However, it differs from existing efforts in multiple ways. Even before the efforts started in this project the Spotlight / featured tools and components on the RaisingTheFloor web site provided a listing of developer targeted tools and components. The GPII Developer Space incorporates this repository along with other developer-targeted content. RaisingTheFloor is committed to curate this content beyond the project via the GPII Developer Space. The original listing also contains project specific listings like the AEGIS: Overview of demonstrators . It is the goal of the GPII Developer Space to provide a platform for such listings in the future and interlink open project results from commercial or academic endeavours in more sustainable way. Today AEGIS demonstrators live on on GitHub such as From GitHub developers can easily fork and use results. We want to encourage projects to bring content to places where the developers actually are, without creating a new place that diverts traffic. Thus, we provide an interface that just provides an alternative interface to existing sites. The same goes for technology specific efforts like the W3C WAI Component Gallery. We were easily able to incorporate most content as it was hosted here. We also depend on external activities like Project A11y to identify open source content. The biggest difference of the component repository is that we have identified over 1000 accessibility related open source components that we started to categorize on .

The Interface for Searching, Browsing and Bookmarking Components

Screenshot of the Developer Space Component Repository

The above screenshot shows the current interface to the component repository with more than 700 curated component entries (the rest is still in the moderation queue). In the main part (1) a summary of different components. For components that were imported the number of followers (stars) and code forks is shown as an indicator for the popularity and distribution is shown (2). Additionally, users can quickly bookmark or rate a component (3).

Instead of having many subcategories (like tools, code, hardware) the interface relies solely on a so-called faceted search. The search field (4) can be used to query the collection. The user may narrow downs this collection by selecting facets that are shown on left hand side of the screen (5). Based on earlier user research we currently support filtering by the following facets:

  • Technology: mostly the used programming language
  • Licence: open source licence type specifying permitted distribution
  • User Needs: Major disability categories
  • Type: related to the usage as independent developer tools or e.g. as programming framework
  • Technique: what strategies to solve accessibility needs can be applied using the component

Example selecting javascript components that support adjusting the contrast

Using this interface the user can quickly apply different browsing strategies such as exploring all MIT licenced components that help with physical disabilities or specifically searching for a reactive web component that changes contrast on a web site. Once interesting components have been discovered

Links to components shown at the bottom of the Accessibility Masterlist entry

The site consequently interlinks content providing a rich browsing experience. By clicking e.g. on a technique the user is redirected towards the Accessibility Masterlist, which in turn lists all possible components but also other educational material. Through the applied categorization the site, thus provide a rich experience and fosters learning and exploration. It also provides a like to practical material such as the components from the theoretical background to motivate real implementations.

Roles within the Developer Space

The concept of roles as we will describe it here is the basis for access control and defining content management processes. A natural person that logs in to the developer


Users of the GPII Developer Space are described using the following five "epics":

  • I develop AT I want to make my product more accessible
  • I want to make an accessible website
  • I teach and research accessibility
  • I make policies on accessibility
  • I want to get the latest on accessibility

While the searching the GPII Developer Space can be done spontaneously (and should not require any documentation or a technical role), we also want to engage those users as prosumers. Logged in users contribute in multiple ways to the site:

  • Provide useful comment and feedback on components
  • Suggest new components and other content
  • Provide feedback on the overall site


Editors are community members or power users. Their main work is to organize the collection of resources thus adding value beyond quantity. In this document, we describe how Editors should categorize content.

Editors are typically volunteers from the RaisingTheFloor consortium and the overall GPII. Categorizing one thousand components needs a large number of volunteers initially. Currently partners from the funded Prosperity4All project took on this job. We believe less volunteers are needed once most of the content is categorized.


Curators are needed to release components. The role of the Curator is to assure the quality of the content concerning both the usefulness and the legal compliance of the content.

The the checks to be done are described in the last section of this document. It should suffice to have a single Curator for the component registry. It makes sense in terms of quality assurance to separate curation from editing. Curators should be contractually bound to the operator of the site (RaisingTheFloor International) in order to protect the operator from potential legal complications by enforcing some rules. Curators could also be seen as community managers or moderators. They have the right to modify, release or withdraw any content.

A special task for the Curators is maintaining the GitHub interface to the developer space as well as adding content into the categorization cue for the Editors.


The role of the Administrator is to maintain the necessary software, define roles and access policies and to oversee the curation process.

One important prerequisite of the whole system is that the Administrator can assign roles to users. In case the system needs to scale also other roles might assign less privileged roles. Currently we are envisioning that most users do not need special privileges, so the Administrator knows and manages all Curators and Editors.

Currently the Administrator is meant to be a web developer with skills in HTML, PHP and Drupal. The development of the code for the repository is coordinated by RaisingTheFloor International as part of the overall Developer Space with contributions by KIT (repository imports), Pushing7 (Drupal integration) and Illunion (feedback).

The overall Developer Space site is built on Drupal 7 technology (for the underlying architecture please refer to D201.5 of the Prosperity4AllProject). The component repository specifically relies on the Search and Facets API that provides the necessary interfaces for efficient browsing via an Apache SOLR server. The curation scheme above is implemented using the Workbench Moderation module. We share those parts with the other content of the Website

. Example of developer contributing content

Administrators should give special attention to the Github Feeds Importer that is described as part of this document.

Adding Components

Suggesting New Components

Users can suggest new components using the issue tracker on GitHub: .

Additions should be shared as direct links to GitHub repositories if possible. However, projects (source code) hosted in other places is also welcome.

Example of developer contributing content

As explained above the Developer Space exists to feature a diverse set of components that an implementer can build into his products or can help him improve his product in other ways (e.g. by testing). The listing's lifeblood is from suggestions from the community. As most open source development has moved to GitHub as a platform (Google Code as well as Microsoft Codeplex have been archived with migration paths to GitHub), it became more and more apparent that we need to support a GitHub centric workflow to cover the majority of open source developments. This includes particularly component from the GPII projects, such as Cloud4All and Prosperity4All.

Curators may schedule new components scheduled for moderation by "staring" the project via GitHub's native interface. This provides an ease two-click workflow to review new suggestions. Using the Developer Space user account in GitHub the Curator can follow the link in the issues (or also e.g. an email with a suggestion), quickly assess the relevance of the suggestion (not categorizing at this point) and click the "star" icon. The item will be automatically scheduled for addition on the Developer Space website (see below).

Staring component on Github to trigger inclusion

Another important aspect of this workflow is that it allows us to disseminate components over GitHub's social network. Additions to the Developer Space will be fed to all followers on GitHub automatically via the timeline visible on GitHub's homepage to signed in users:

Screenshot of user riedel of mainpage of

Strategies for finding new components

One important feature of the staring feature is that it works both ways. In a addition to having followers, that are informed about new findings, we are informed about new finds from the people in our social developer network. While the automatic suggestion feature of GitHub mostly focusses on popular, content that is either too unspecific to assistive technology or already included, the simple timeline view helps to find new things quickly as we are following accessibility related developer profiles. See image.

Filtering user profiles for interesting components

Another strategy to find new content is to identify early adopters of accessibility related technology (e.g. by following git commits to knowledge basis such as the A11Y projects). By listing all starred components from their GitHub profiles we are quickly able to find new components (see below). If the user shares relevant findings, we will continue to follow this user to get updates via our own timeline.

Github timeline for Developer Space curation user

Understanding the Importing and Updating Pipeline

Drupal Feeds Plugin

New GitHub projects are periodically imported via a Feeds plugin on

Importing task aumatically run every 3 hours

The whole workflow for aggregating new GitHub projects is backed by a Drupal module that was developed at KIT in the prosperity project to particularly fit the needs of the Devloper Space (but can be used beyond this). The module still supports two interfaces to GitHub. One remote entity interface that allows interfacing GitHub content as Drupal entities via GitHub’s API and one to autofill content using fields from GitHub.

Currently the Feed plugin sources the following information automatically from GitHub and maps it into Drupal:

  • Component name
  • Component author
  • Short Description
  • Readme file
  • Licence
  • Programming Language
  • Descritive Tags
  • Number of stars
  • Number of forks
  • Website link

The Mapping of Github information to DSpace

We use the same internal mapping logic to extend the Feeds interface that is used to import new component listings that are displayed on the GPII Developer Space. The API particularly supports the pagination of queries to Githubs open API and calls to fill out child elements such as the description.

The listings are automatically updated (due to some performance issues on caching, currently you need to clear the Drupal cache manually to accept updates). Newly imported content is not yet published but must undergo categorization first. We use the GitHub URL as a unique identifier for updates. This means that renaming of repositories might lead to duplicates. The next image shows the current mapping of the importing workflow that might be adapted to future needs.

Configuration of the github mapping

In order to support such a large number of queries we need to obtain a GitHub API token. The API token can be configured inside the Drupal configuration page and should be copied from the GitHub account settings of the GitHub account. The API token also identifies the account that we use to base for import. Future versions might support an even more integrated workflow, e.g. for un-listing components simultaneously or for feeding suggestions via the web interface directly to the issue list. The current source code of the components is available at:

Using the Feeds Importer, we can add fields to each component listing that will be retained during synchronization. This particularly includes the categorization (see below)

In addition, Editors and users can add other content such as reviews and comments to the component. Components can also be interlinked throughout the site, e.g. in tutorials or through the categorization.

Editing and Categorizing Components

Once the component is successfully imported, Drupal adds it to an editing and curation queue as unpublished content. The Editor prepares the document for publication and puts it into the curation queue where the Curator schedules it for publishing (see next section).

Editor picks item from Queue

Editor picks item from Queue

0. Read the description of the component: if you do not understand what it is about or why it concerns accessibility, do not bother and go to the next one, this is the first filter.

1. Decide if it is a component at all: not everything from GitHub is actually a component, there is also things like documentation. We consider automatically crawling other parts from GitHub later. The Editor should in any case ignore such items for now

2. Decide if the components is either a framework (like infusion, AsTerRICS, react): The Editor should decide if something is framework specific (like a react autocomplete field), a testing tool, a code snippet or a whole implementation or neither of the above. This is important to narrow down common use cases of developers.

3. Check if the component is particularly addressing a need of one of the major disability classes: We have tried multiple classification schemes for disabilities. This is the most pragmatic one we found and it helps especially people new to the domain.

4. Specify the type of solution in terms of the Masterlist: This is the preferred way of looking for many components. An educated developer can first look at the problems, find a solution and chose (sometime ready-made) implementations that provide such a solution.

5. Check if the components relates to a requirement as specified by the EN (Section 5-13 of We currently have not implemented that in the search, but we believe that an integration with procurement regulations provides much benefit for commercial developers.

6. If you are done, mark the component for publishing and go to the next one: An Editor may leave comments for review by a Curator if he is unsure or discovers any problems.

The screenshot below shows the interface for categorization.

Categorization Interface


Many developers come with a certain problem at hand. This normally means that they are looking for a specific kind of thing; they can build in, use themselves for development or add e.g. as extra hardware. We currently have identified the following classes:

  • Libraries & Snippets: independent components, that can be built in
  • Framework-specific: things that work in the context of certain development framework
  • Framework: a complete set of APIs and components
  • Testing & Development: typically tools that help during development to increase quality or save time
  • Hardware: things that need to be produced physically
  • Web API: hosted APIs that can be used easily

We have found that those categories or combinations of them help finding fitting components for many use cases. They might be efficiently used in combination with the full-text search (e.g. looking for "framework-specific" (facet) "react" (full-text components). When categorizing, please keep in mind this use. "Over-tagging" might lead to many irrelevant hits (e.g. every "Framework" contains "Snippets and Libraries", but most commonly it is used as whole, so do normally not tag both). "Under-tagging" might lead to few things being categorized. We provide an "other" category to identify missing categories, but this should not be used too often: the Editor should specify in the comments why something was hard/impossible to categorize).

Note: We are focussing on open source components, while also listing commercial solutions that help developers. Particularly the last item can also contain interfaces to non-free interfaces. Sometime here the licence filter is misleading as the code for accessing the API is free but you need access to commercial services (we might add something like: in the future). The same might be true for hardware. The minimum criterion should be that those things could be openly build into existing or new solutions.


In D202.1 we have looked at many categorization schemes. While most schemes fall short of describing the specific needs of a person and do not really address the idea of inclusive design or inclusion by design, particularly easy categorization helps novice developers to understand the domain. The following categories can be selected by users of the DSpace:

We understand that this approach of focussing firstly on "major" classes may often leave out the tails of the tails and sometimes might lead to addressing "red flags" only. However, providing those major categories helps developers finding what they want more easily. Categorization is semantically always discrimination, with a faceting approach we, however we offer this only as one way of browsing and refining. In addition, multiple facets can be selected: e.g. "Blind" and "Deaf", but we cannot ensure that the component might help a deaf and blind individual, however it will narrow down the number of items. This narrows down the search space rapidly.


As stated above the Accessibility Masterlist is our own developer focussed ontology for categorizing solutions. A component should be part of a solution to a problem commonly found in accessibility. The developer space constantly looks for new strategies and solutions, however, the list as it is currently maintained, contains most individual strategies that have been followed. However, categorization of components is a good way to look constantly for new approaches. If you cannot find a matching Masterlist item, please provide detailed comments. It makes sense for an Editor to be become familiar with all Masterlist items on a high level, this can partially be done while categorization. A good starting point is looking also at existing similar items that are already categorized.

Two problems typically occur. Firstly, the item only helps the development process (in contrast to the targeted end user) and so can be widely used. This is true for many testing tools. It is difficult to specify concretely the addressed solution. However, we do not want to list tools such as common continuous integration frameworks with no specific link to accessibility. So tagging a solution is also a check for relevance. One solution is finding more fitting subcomponents (e.g. accessibility related plugins or workflows) to be listed here. Many testing and development tools are currently tagged as "Transform content to conform to accessibility standards", although still manual effort is needed. This seems acceptable in the context of this component. While tagging e.g. a testing tool with "Help Minimize Errors" is likely not correct if it relates to the developer (although it leads to interesting thoughts around usability). Therefore, the Editor should be sure that he understand the description linked to the tag, in this case e.g.: "This is an overarching feature that includes many error-minimizing technique. [...]Any disability may increase the risk of an error, and may make it difficult to recover from mistakes. This feature helps to reduce the number of errors "(see

The second problem is that many inclusive AT frameworks provide many different solutions. Here it is again important to understand that the reader should understand the connection to the AT domain when reading the description. The Editor should not add too many solutions to an item that require in-depth knowledge of a framework to understand them. It might be important to link tutorials and other content (that address specific solutions). The same is actually true for frameworks with all disability groups. A user that looks for a specific solution will typically not understand the link between a general plugin framework and cognitive disabilities, although one might build solutions for this user group with this framework. Categorization should always been seen as providing benefit for people using the search interface.

Procurement Requirements

A separate categorization strategy for procurement scenarios that we are following does not originate from the user research on the search interface, but was motivated particularly through potential business cases and the work on standardization (and consequently regulation). The process initiated by mandate 376 will have a major impact on procurement of IT with relationship to accessibility. Many companies will be faced with the need to fulfil technical requirements, that are specified as part of standard EN 301 549 "Accessibility requirements suitable for public procurement of ICT products and services in Europe". The standards is aligned with existing standards like WCAG2 (which is a subset of this categorization). Consequently the standard is quite complex for categorization. Integrating this part is the latest addition to the Developer Space component repository and thus still incomplete and under testing.

The idea is to support a procurement work flow that starts with the creation of a "Call for Tenders" as it is supported by . The typical output will contain references to technical requirements that need to be evaluated for someone answering the tender ( This amounts to a gap analysis for many existing products. By tagging components (and other resources in the GPII Developer Space) by requirements from the standard, we can extend this work flow to enable companies to answer to tenders by extending their products through new solutions. This is a critical interaction for globally improving accessibility (as not all IT (non-public) will be required to fulfil strict requirements). It provides furthermore an important potential entrypoint to the Developer Space.

While it is an intriguing idea that anyone can by including just bits of open source software can make their products fit for public procurement, this raises far too high expectations. Thus we decided in collaboration with the standardization task to add a qualification attribute to the categorization interface (see screenshot below). Many time more steps are needed to fulfil requirement. We want to express that by explanations and a level of support mapping:

  • L1: Resource provides background information or example
  • L2: The resource provides guidance related to the topic/requirement or tools support to the developer.
  • L3: The resource support the fulfilment of requirement at least partially if correctly integrated.
  • L4: This resource allows a developer to fully fulfil a requirement if correctly used. node 3743 edit en301549.png

Curating and Publishing Components

While the GPII Developer Space is a community initiative, we have learned the hard way that providing quality needs structure and individual commitment. Especially in the early phase towards sustaining the project and also an organizational structure responsibilities are important. Raising The Floor International is committed to host the the Developer Space. Therefore at the moment administration and curation are roles mostly implemented at RtFI. As the community grows this concept needs to certainly scale, but it currently requires close coordination. The curation role for the developer space repository especially means taking responsibility for sustaining the content and consequently for the sustainability of the site.

Minimal Requirements for Including Components

By selecting potential components and by publishing components Curators need to define the scope of the site. It is important to understand that the Developer Space component repository should be focussed, complete in certain areas and complete in breadth of relevant areas in the AT domain. We have opted globally for a very inclusive strategy that has found more than one thousand interesting components. We are still missing relevant ones and will most certainly have quite a few in the list that might not have much value. However it is important that we provide particularly information and also software that addresses the tails of the tails, while ensuring the attractiveness for newcomers to the domain. This is why we will list as many components as possible and try to address quality by providing indicators through rating and metrics, that allow the users to judge quality.

However, there are minimal requirements. Foremost we have to clarify the legal and ethical consequences of including content. As we are mostly listing open source, we normally do not have copyright issues as long as attribution and links are provided to the original content. However, particularly for free to use or commercial components the content should be checked quickly, if the content (images, text) can be legally displayed on the site.

Other than that there should be a minimal documentation and linked information that allows judging quality quickly. This also includes that overly promotional postings should not be allowed particularly for commercial content. Instead of rewriting content (eventually leading to responsibilities regarding correctness), the Curator should delay listing if necessary and clarify aspects with the original publisher. This includes copyright, missing information and ethical issues with descriptions alike.

Within the internal process, the Curator should perform final checks,for if the categorization seems to make sense or if the Editor left comments. In this case of doubt a second Editor should be asked to review the categorization. Normally after a quick check the Curator can accept the categorized components. Overall this process should take two minutes per edited component maximally to scale.

Scheduling for Publication and Maintenance

Once an Editor has changed the state to "Needs Review" the item will appear in the queue of any user with a Curator role. The Curator checks the categorization for soundness (see above) and might resolve any comments left by the Editor. Once this is done the Curator schedules the content for submission. We expect Curators to work perhaps once a week on components, but we want to have the repository grow as people visit the site regularly. Accordingly, the publishing of the content is scheduled, so that users see new content each day. The image below shows recently scheduled content. This step is particularly helpful is if content is dynamically updated on the front page showing new additions. Overall the Curators should keep the overview of the overall site. This means that Curators should actively interlink content based on their knowledge that goes beyond categorization (e.g. linking tutorials, etc).

Curators are also in charge to check feedback delivered via the rating and feedback forms related to the listing. Particularly if comments are related to wrong categorizations or missing links, Curators should review component listings. admin workbench needs-review.png

Summary and Future Work

The Developer Space Component repository needs constant refinement. Particularly we have multiple items on our wish list that we want to include in the future:

  • Integration of other hosting sites like SourceForge or BitBucket
  • Badges for listings (based e.g. on that make it possible to take categorization back to the original documentation and provide links into the GPII Developer Space
  • Crawling of images as thumbnails and featured images
  • Incentivation and gradual Qualification based on a gamified point system for Editors
  • Improved integration with other sites, particularly with that provide interlinking possibilities.
  • Integration with continuous integration/testing and package installation like npm or nuget based on automation

We are currently migrating the source code and the issue tracking for all components. We are inviting contributors to continue to develop and test functionality technically. We are happy for all feedback (e.g. on the discussion page for this article or the Mailing List