Related to participative and participatory design

LESSON 1: A one for all solution may prove difficult in some cases, because requirements may become exclusive to one another. A striking example was the desire of various blind users to use screenless mobile devices, something which obviously excluded e.g. hearing impaired users. Therefore, end-user involvement must be well balanced and guided.

LESSON 2: Developers should not be developing on an island, but should ensure that throughout they crosscheck what they do with end-users, and only deliver a version once it has been approved by an (experienced) end-user.

LESSON 3: Every iterative cycle should address all open issues, to avoid there is a cascade effect.

LESSON 4: A developer develops only after users have indicated this is a feature they desire and in a specific manner. Often developers tend to decide for end-users, based on limited (expert) knowledge of a given disability.

LESSON 5: Every cycle should provide full installation details to testing groups, including what versions of OS are needed, what JRE, etc. as this did cause major delays due to incompatibility between 32/64 bit OS and JRE versions, etc.

LESSON 6: If something is out there already, do not reinvent the wheel but check how it could be integrated in ongoing work, respecting copyrights, etc.

LESSON 7: Piloting proved to be cumbersome due to lack of AT knowledge of the people with disabilities. As a result outcomes were not always trustworthy and had to be rechecked with expert users. This was especially the case with users with vision impairment and the usage of screenreaders to access ARIA webpages. As a result, we had to rely on expert users to get reliable feedback. This raises of course another concern on general AT knowledge, as was already outlined also in the AEGIS survey that took place in 2008-2009.