2017-05-10 - Accessibility, Activity List
We had two lengthy discussions at our hangout this week
The first half of the discussion was around how we describe whether an opportunity offers supports for people with disabilities.
Its clear that is a complex issue. A participant looking for opportunities will be interested in a whole range of information that may be relevant to them making a decision, for example:
- Accessibility of venue (e.g. wheelchair access)
- Availability of specific equipment
- Whether a physical activity or sport is specifically designs for disabled participants, or could be tailored if there were support from a session leader. See, e.g. paralympic/deloitte classifications whether a session leader or organiser has experience in supporting people with specific disabilities or impairments
- Whether there is scope to tailor an individual session to needs of participants
- Their understanding of their own needs and capabilities
The discussion on list and on the call highlighted that:
- There is currently a reasonably consistent list of terms used to categorise disability support at events. Summarised here.
- There would be value in there better advice for event organisers around what it means to run inclusive sessions for different types of disability and impairment
- There is potential for some innovation around the discovery and description of inclusive events, to better support people with disabilities, including more user testing of terminology which is currently driven by reporting requirements
This covers a lot of ground and not all of it is within scope of this standards group (e.g. general advice for event organisers).
On the call we proposed some revisions to the specification and primer:
- Creating a small controlled vocabulary of terms for describing disability support, based on the current commonly used terms, e.g. Physical Impairment, Hearing Impairment, etc. These will have clear descriptions, to encourage consistent use
- Add a new property that will allow one or more values from this vocabulary to be used to "tag" an Event
- Add a new description property for events to specifically capture notes about disability support available at a session, this could include experience of leaders, notes on relevant equipment, etc
- Revise primer to include examples of using the above
I still think this provides the simplest way forward that will allow current platforms to publish their current data under an open licence. It's consistent with our existing approach of encouraging platforms to start sharing data they currently have, before looking at improving practices across the sector.
I think this gives a better starting point for improving categorisation across the sector. For example innovators can test new discovery interfaces that might drive improvements to the standards/vocabulary and the underlying platforms. We can revise the terminology and specification in line with implementation feedback which will give us some strong requirements.
The alternative is to develop a new set of terminology and approach, and then work with platforms to implement this. The downside here is that will delay publishing of existing data, even if those descriptions may be sub-optimal.
In the second half of the call we reviewed the progress and plans around developing our shared activity list.
This call was our first chance to discuss the initial progress of developing the list, lead by Kim, Becky and Jade. The ongoing, working draft version can be found here.
We discussed:
- Requirements for the list, e.g. its use in supporting searching and browsing for opportunities, integrating data across platforms and in reporting. There's a clear need to balance these requirements: the list needs to support searching by end-users, but data integration is also an important enabler for OpenActive as a whole
- The top terms of the list. The key decision was to remove the top-level split between Sports and Physical Activities, if these are retained they will be handled as collections. This reduces the list to 2 levels, not 3
- Whether to have a single or multiple levels in the hierarchy. I think the consensus, based on our previous discussions is to have multiple levels, but also note we need to include, e.g. in the primer, some notes about how the list can be used, to support searching
- Need for more detailed review of some terms, including their labelling, descriptions, etc
- Focusing on the terms and their metadata before working further on collections
- Using trademarks as an indicator for including branded programmes in the list. It's one useful indicator of visibility to participants
- That the list may need review by additional groups. Jade has reached out to ukactive for input.
- That the list should include unique identifiers to help with versioning
- That the term labels will be formatted for display to users.
The key debate was around the process for moving forward. There were some different views about the best way forward, e.g:
- Just publish the list, after some further review by the group
- Inviting further review and feedback from specific groups before publishing more widely
The balancing act here is fulfilling immediate needs of developers who are looking to use a list, whilst ensuring that it is reasonably coherent. But without spending a huge amount of time trying to create a perfect list.
Based on the discussion, I think that the way forward is to:
- Share some editorial guidance, that will help us draft the list and inform its development
- Set ourselves a target date for publishing a first version
- Work iteratively, aiming to:
- refine the list within the group, over the next few weeks
- then invite comment and feedback, within a clear time window, from a wider group (to be determined)
- ensure that it is clear to everyone, in the group and beyond, how and when feedback can be provided, and what type of feedback we are looking for continue to work within the Google spreadsheet for now, to collate feedback
- review the list again in our next call, with feedback on the document in the meantime