Meetings (2021)
Meetings - Technical Working Group
Meetings Archive
2018-10-24 - Accessibility requirements
Update on the accessibility requirements in the OpenActive spec and proposal to extend these in the next versions of the specifications
Summary
OpenActive accessibility requirements approach so far
In the past we looked at data being published by different activity providers and tried to find commonalities. This led to a list of AccesibilitySupport dropdown options + a free text field.
Some people in the group were concerned that data at this level isn’t currently collected/known by activity providers and that we should focus on getting this level of adoption. Following this we can see what other data we have, rather than creating gold plated standards that providers can’t give information against.
New suggestions
There are two new suggestions (SpecialRequirements & IsWheelchairAccessible) but in the call we mainly focused on the ‘SpecialRequirements’
IsWheelchairAccessible
The group noted that there is difference between something being physically wheelchair accessible, and really being suitable or pleasant for wheelchair users - so user testing the definitions and guidelines is important.
SpecialRequirements
There was some confusion as to what these tags actually meant: should the categorisation be taken to mean that those with the specified condition are welcome, or the activity has to be specifically targeted to that group? Are they based on conditions or people’s needs (e.g. ‘strokes’ have different severity levels)? Could a more general field of ‘disability aware or friendly’ be easier for an activity provider to tick?
Wording: ‘impairments’ may not be very accessible/relevant to people - but it was noted that this may not be what is displayed to a consumer anyway
In general the group thought that it could be useful to be able to give this information if available but:
- It would be difficult for an activity provider to determine whether they were friendly to ‘strokes’. OpenActive has previously talked about making questionnaires & guidance to help activity providers standardise, but this hasn’t yet been done, and OpenActive may not be best placed as non-experts. This has led to a situation where some providers tick everything because they want to run an inclusive session and some providers don’t tick anything because they are nervous about making this judgement.
- By allowing activity providers to self identify, there are lots of data quality risks, whereas it is possible for someone independent say ‘there is disabled parking space or changing rooms suitable for wheelchair users’ (see disablego link in slides).
- There are a range of ‘strokes’ too, which lead to a range of cognitive + physical issues. In the options given in the list they seem a varied bag in terms of granularity and types of support someone might need.
- There’s a difference between events specifically targeted at someone specific (maybe for more severe cases) and events that are friendly towards people with conditions but aren’t aimed at them. It was felt important to be able to tag events if they’re specifically being run for rehabilitation rather than being termed ‘suitable’ for lots of conditions but aimed at the general public.
- If someone needs significant extra support they may be with a carer - so it could be most useful to understand whether the person leading the session is disability aware and friendly. This becomes a question customer experience too.
Queries about the scope of accessibility requirements
We discussed accessibility/suitability of a particular event vs the accessibility of the venue vs the accessibility of the activity type vs the provision of equipment: for example ‘is there a racing wheelchair or an adapted boat’ available. We felt that this could live in the free text field, as having the equipment available is not something people would necessarily expect to be able to filter results on, and this would stay in line with the rest of the spec which groups equipment in free text fields. We noted Active Places does has equipment fields based on location.
Queries about the process
It was asked whether the categories and wording been run past people with disabilities and/or there had been a formal consultation? The ODI hasn’t run a consultation, but have worked with organisations such as Activity Alliance who do, and have used wording suggested by them. Disabilities Rights can create focus groups (which don’t focus on sports, ideal for our aims of getting inactive people active) and recommend carrying out direct consultation, from the beginning. We think we have enough suggestions and data to be able to test with users. We want to understand whether these are the categories people want and also to understand how inaccurate data is going to affect people’s uptake of activities.
It would also be useful to do some testing/research with data providers - how do they react to the number of choices and is it information they are comfortable providing?
We asked what what other organisations are currently doing:
- the British Paralympic Association have tried to tackle this and find the Paralympic categorisations are too specific in some areas and don’t cover all the areas that consumers want. The existing categorisation looks to be like the level of detail required for their new website, and they are happy to feedback their experience of using the categorisation to support this project.
- Richmond Group of Charities support a wide range of conditions. Some of their work is around message testing - could we do this at the same time? They will follow up and see what the call to action could be. They need to think about whether they want to work at the level of detail existing in the spec, or test some of the new proposals.
Next steps
- 1.Izy & Cecilia (Sport England) to touch base with Kirsty (Disability Rights) & Michelle (Richmond Group of Charities) as well as Activity Alliance and work out what might be best re: user testing/consultation with disability groups - and then Izy to feedback to the group.
- 2.The next call for the subject will be to review the results of that.