Ei ole kiinteää määräaikaa, joka pätee jokaiseen sovellukseen. Pieni sovellus, jossa on rajattu määrä näyttöjä ja siisti koodipohja, voidaan saada haluttulle tasolle muutamassa viikossa. Sovellus, jossa on paljon räätälöityjä komponentteja, useita alustoja ja pitkä historia teknisestä velasta, vie pikemminkin kuukausia. Suurin vaihteleva tekijä ei ole näyttöjen määrä, vaan se, kuinka suuri osa käyttöliittymästä on rakennettu iOS:n tai Androidin vakiokomponenttien ulkopuolelle.
Karkean indikaationa: sovellus, joka koostuu pääosin vakio-UI-elementeistä ja jonka tiimi on jo perehtynyt saavutettavuuteen, voidaan käytännössä usein mukauttaa kuudesta kymmeneen viikkoon. Sovellus, jossa on paljon omaa käyttöliittymää, animaatioita, mukautettuja eleitä tai kolmannen osapuolen upotettujen ohjelmointirajapintojen kirjastoja, nousee helposti kolmesta kuuteen kuukauteen, yksinkertaisesti siksi, että jokainen komponentti on tutkittava erikseen ja joskus rakennettava uudelleen. Nämä eivät ole jäykkiä rajoja, vaan käsitys siitä, mihin suurin osa käytännön projekteista tyypillisesti päätyy.
Mikä todella määrää läpimenoajan
Projektiin kuluva aika riippuu vähemmän laista ja enemmän kolmesta käytännön tekijästä. Ensinnäkin: onko käyttöliittymä rakennettu käyttöjärjestelmän vakiokomponenteista vai pääosin omaksi rakennettu? Vakiokomponentit tarjoavat saavutettavuuden usein jo suurelta osin valmiina. Omiksi rakennettavat komponentit on varustettava oikein merkinnöillä, tarkitussekvensseillä ja ilmoituksilla näytönlukijoille yksi kerrallaan. Toiseksi: kuinka paljon ulkoisia komponentteja sovelluksessa on, kuten maksuja käsittelevät moduulit, karttanäkymät tai kolmannen osapuolen chat-ikkunat? Nämä jäävät usein oman tiimin suoran hallinnan ulkopuolelle, ja toimittajaan ottaminen yhteys kestää yleensä testaamista kauemmin. Kolmanneksi: onko olemassa jo testausmenettely näytönlukijalla todellisella laitteella vai pitääkö se vielä rakentaa? Jälkimmäinen kestää ensimmäisellä kierroksella eniten aikaa, mutta maksaa itsensä takaisin myöhemmillä päivityksillä.
Missä aikataulut käytännössä jumittuvat
Suurin osa viivästymisestä ei synny tekstien tai värikontrasteina muuttamisesta, vaan vuorovaikutuksesta, jota ei voi käyttää näppäimistöllä tai näytönlukijalla: vetää siirtävä liike ilman vaihtoehtoa, modaalinen ikkuna, joka ei pidä fokusta, tai lomake, josta virheviestejä ei ilmoiteta. Tämänkaltaiset ongelmat tulevat usein näkyviin vain manuaalisissa testeissä näytönlukijalla, jota automatisoitu tarkistus ei voi täysin korvata. Joka luottaa vain automaattiseen tarkistukseen, havaitsee nämä pullonkaulat yleensä liian myöhään projektissa, mikä pidentää läpimenoaikaa. Hyvä lähtökohta on siksi saada muutamalla kysymyksellä ensimmäinen indikaatio siitä, missä sovellus tällä hetkellä on, jotta aikaa vievät komponentit nousevat esiin ajoissa sen sijaan, että niitä löydettäisiin juuri ennen toimittamista.
Myös sovelluskaupan tarkistussyklit vaikuttavat: muutos, joka parantaa saavutettavuutta, täytyy silti käydä läpi tavallinen kyseisen kaupan tarkistusaika, ennen kuin käyttäjät huomaavat muutoksen. Tämä on kehitystiimin hallinnasta riippumaton tekijä ja kuuluu jokaisen suunnitelmaan kiinteäksi aikapuskuriksi.
Pysyttäytyminen saavutettavana julkaisemisen jälkeen
Sovellus, joka täyttää vaatimukset tänään, saattaa jättää ne täyttämättä seuraavalla päivityksellä. Jokainen uusi ominaisuus, jokainen uusi näyttö ja jokainen muutettu työnkulku ansaitsevat saman huomion kuin ensimmäisellä kierroksella, muutoin ongelma hiipii takaisin. Se on myös syy siihen, miksi velvoite ei lopu yhteen testaukseen: omaan arviointiisi on pysyttävä ajantasaisena, mikä vaatii toistuvaa sykliä kertakaikkeisen projektin sijaan. Saadaksesi taustan siitä, mitä sinulta tarkkaan ottaen vaaditaan, niin kunkin tilanteen mukaan valittu tausta on sopiva lähtökohta.
Mitä axessia.eu tekee ja mitä se ei tee tässä prosessissa
Axessia testaa, asettaa prioriteettijärjestykseen, dokumentoi ja valvoo: skannaus näyttää, missä sovellus tällä hetkellä on, raportti esittää havainnot tavallisella kielellä priorisoitujen luettelon muodossa, ja vakuutus sekä parannussuunnitelma dokumentoivat, mitä on tehty ja mitä on vielä tehtävä. Manuaalisia tarkastuksia ja sovelluksen itsensä korjaustöitä ei ole osa tätä; ne kuuluvat kehitystiimille tai osapuolelle, joka sovellusta rakentaa. Miten skannaus tarkalleen ottaen toteutetaan ja mitä lähteitä siinä käytetään, selitetään seuraavalla sivulla: sivulla, joka käsittelee tietojen tuottamisprosessia. Kokonaisen hankkeen kustannuksista, mukaan lukien raportti ja vakuutus, löydät tietoja sivulta tilauspakettivertailussa.
Halutessaan tietää, missä konkreettinen sovellus tällä hetkellä on, kannattaa aloittaa axessia.eu:n ilmaisesta quick-scannista. Se antaa muutamassa minuutissa ensimmäisen kuvan ilman, että siihen tarvitaan tiliä.