We are working on enhancing our website for the upcoming changes to the ADA. We have SYOS covered thanks to the new "Reserve Held Seats" option for T_DEFAULTS with V10, which now works with ReserveTicketsSpecifiedSeats and that we use holds for wheelchair seats.
Initially we decided we would only enhance the SYOS ticketing path, but we have situations where we deliberately disable SYOS due to volumes, leaving Best Available as the only option. The problem is that while ReserveTicketsEx allows the parameter for special requests, wheelchair being one of them, that will not work for held seats.
Has anyone done anything dealing with wheelchair seats and Best Available?
Thank you in advance.
Paul
What we're attempting to do is enhance the ability of the best seating system to seat both wheelchair locations and companion locations appropriately. So in essence, the new procedure will look at the number of wheelchair location requests as compared to the total number of seats requested. The difference between the two will be considered companion seats, which will be divided as equally as possible between the number of wheelchair location requests. Then the process will select each wheelchair location (in normal best seating order) and then attempt to select that wheelchair location's companion seats as close as possible to the selected wheelchair location. Calculating "close as possible" is done using both row and seat contiguity.
I can't get much more specific than that until we are through with development and testing. But our goal is to both adhere to the spirit of the new regs which call for being able to accommodate best seat requests in a like manner whether wheelchair locations are included or not, and to stay backward compatible with the existing best seating process.
Was this ever implemented? Did I miss the solution in another thread?
We implemented this internally for two reasons: 1) the accessible seating system in Tessitura wasn't going to be updated by the drop-dead deadline (um, March 15th, 2011) and 2) our interpretation and implementation of the rules was a little different to the direction that Tessitura went: namely that the 2nd and 3rd companion seats could be assigned from nearby wheelchair spaces. That is to say, our layout typically looks like this (S: Standard, W: Wheelchair space, C: Companion seat):
SSWCCWWCCWWCSS
So someone asking for one Wheelchair and three other tickets would be entitled three companion spaces, but we would provide two Companion seats and one Wheelchair space, e.g.:
SS[WCCW]WCCWWCSS
To do this, I have had to divert online requests that include wheelchair spaces, and instead of using Best Seat API methods, I pull a custom table that matches wheelchair spaces in each venue with companion seats in order (set up by the box office manager), and run my own (rather complex) algorithm to generate a specific seat request (or identify that the request cannot be executed).
--Gawain