Verkkosaavutettavuuden tekniset perusteet. 3.1 Välisoitto

Transkriptio

1 3.1 Välisoitto Tekniikka on todellinen hengen voitto aineesta, mutta joskus tekniikka näyttää silti saavan ihmisistä yliotteen Teknologian tarjoamien mahdollisuuksien ja sisältämien rajoitteiden osaaminen on perusedellytys toimivan suunnittelun perustana Motto: on helppo kritisoida, hankalampaa on "tehdä oikein" 39

2 3.2 Osatavoite, WCAG 1.0 pähkinänkuoressa (1/2) Verkkosisällön saavutettavuusohjeen (Web Content Accessibility Guidelines 1.0, WCAG 1.0 ) sisältö lyhykäisyydessään: 1. Tarjoa samansisältöinen vaihtoehto ääni- ja kuvaperustaiselle tiedolle. 2. Älä luota yksin värien käyttöön. 3. Käytä merkkaus- ja tyylikieliä ja käytä niitä oikein. 4. Koodaa tekstin luonnollinen kieli selvästi (dokumentin tekniseen otsikkoon). 5. Käytä taulukoita siten että ne voidaan esittää eri tavoin ja eri välineillä. 6. Varmista että uusia teknologioita hyödyntävät sivut toimivat hyvin myös vanhemmilla asiakasohjelmilla....jatkuu 40

3 3.3 WCAG 1.0 pähkinänkuoressa (2/2) 7. Varmista että käyttäjä voi hallita sovelluksen aikariippuvia osia. 8. Varmista sulautettujen tai upotettujen käyttöliittymäosien suora saavutettavuus. 9. Suunnittele laiteriippumattomasti. 10. Käytä ratkaisuja jotka toimivat myös tällä hetkellä (käytä tarvittaessa väliaikaisia ratkaisuja) 11. Käytä W3C-teknologioita ja ohjeita. 12. Pidä käyttäjä jatkuvasti selvillä asiayhteydestä ja sijainnista sovelluksessa. 13. Tarjoa selkeä navigointimekanismi. 14. Varmista että dokumentit ovat selkeitä ja yksinkertaisia. Ilmeisestikin ohjeen toteuttaminen edellyttää (myös) teknistä osaamista 41

4 3.4 Tekniikka, ohjeet ja standardointi, peruskysymyksiä Tietotekniikasta kirjoitetaan "teknisiä määrityksiä", saavutettavuutta "ohjeistetaan" miksi? Koska... - toimiva tietotekninen standardi jättää paljon liikkumavaraa sen soveltamiseen - esim. asiakirjan sisällön liian tiukka standardointi koetaan yleensä luovuutta rajoittavaksi tekijäksi Miksi standardeista kannattaa puhua? Koska... - standardiin tukeutuminen tuo olemassa olevia sovelluksia ja välineitä - standardointi tarjoaa (liike)taloudellisesti järkevän tavan kehittää sovelluksia (erityisesti PK-yritysten näkökulmasta!) 42

5 3.5 World Wide Webin (WWW) tekninen yhteensopivuus Perusidea: Web nimeää ja välittää resursseja joiden esitystapa (voi siis olla useita) voidaan tarvittaessa valitaan päätelaitteen tms. mukaan - nimi (verkko-osoite), resurssi (entiteetti, "thing"), esitystapa Yhtenäinen nimeämiskäytäntö URI ja tiedonsiirtoprotokollat (HTTP) asettavat yhteensopivan Webin teknisen perustan - Uniform Resource Identifier - Hypertext Transport Protocol "Arkikielessä" resurssi ja sen esitystapa usein samaistetaan (mutta oikeasti ei 1:1-suhdetta!) Kuva: W3C/TAG

6 3.6 Tiedon esitystavan yhteensopivuus Web välittää dokumentteja jotka voivat koostua useasta tiedostosta - (tarkemmin: Web välittää yksittäisiä tiedostoja, yhteen loogisesti kuuluvia tiedostoja ja/tai entiteettejä, "XML-fragmentteja") Sisällön näkökulmasta keskeistä on tiedon käyttötapauksista (prosesseista) sopiminen; tekniikan näkökulmasta erilaisista tietorakenteista sopiminen Koska tekninen standardointi tähtää mahdollisimman laajaan sovellettavuuteen, pitää esim. sovellusten saavutettavuus käytännössä ohjeistaa erikseen Webin Perusinfrastruktuuri on käsitteellisesti erittäin yksinkertainen - dokumenttien koostaminen, yhteyden tilan käsite, tietoturva, versiointi, yms. hoidetaan sovellusten tasolla 44

7 3.7 Standardoinnin tasot, luonnehdinta Toimiva Web-standardointi koostuu eritasoisesta työstä Saavutettavan suunnittelun todellinen haaste on kokonaisuuden (ei yksittäisen tekniikan) monimutkaisuus Erityisen pulman muodostavat käytännöt: toteutuksen tekniseen suunnitteluun saatetaan (kukaties ajattelematta) uhrata enemmän resursseja kuin esim. prosessien saavutettavuuden suunnitteluun 45

8 3.8 Webin standardipinon yleisrakenne Saavutettavuus sovellusten sanastot yms. merkkausk. yms. Tiedonsiirto 46

9 3.9 Pari sanaa XML:n ideoista Webin merkkauskielten melko yhtenäinen tekninen perusta helpottaa - eri sovellusten teknistä ja semanttista yhdistämistä, - Web-sovellusten opiskelua sekä - välineiden ohjelmointia (siirrettävyys). Sisällöllisesti keskeinen standardoinnin muoto ovat eri sovelluksiin tarkoitetut merkkauskielet Extensible Markup Language eli XML tarjoaa perustan eri sovelluksiin kehitettävien merkkauskielten tekniikalle - yhtenäinen merkistö ja merkkauskielioppi (<e a="v"><!-- elem. --></e>) - sovelluskohtaiset XML-tekstiformaatit ja yleiskäyttöiset välineet 47

10 3.10 Esimerkki: XHTML-dokumentti XHTML-dokumentti on XML-dokumentti joka rakenteellisesti noudattaa tiettyä dokumentin tyyppimääritystä (DTD) <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" " <html xmlns=" xml:lang="en" lang="en"> <head> <title>virtual Library</title> </head> <body> <p>check <a href=" </body> </html> <!-- Mod. --> XML "näkyy läpi" XHTML-sanaston pohjalla: fyysinen ja looginen rakenne (tiedosto ja elementit), kommentit yms., nimiavaruuden käsite, jne. XHTML-dokumentin kirjoittajan ei tarvitse tietää "kaikkea" XML:stä (koska XML DTD ohjaa teknistä yhteensopivuutta) 48

11 3.11 Hypertext Markup Language, HTML HTML on tarkoitettu verkkosivujen sisällön kuvailemiseen, tehtävä on: - sisällön loogisen rakenteen kuvailu (ulkoasu on sovelluksen heiniä) Useita suosituksia (ks. - vanhat HTML-versiot (2.0, 3.2) ja HTML XHTML-perhe - XHTML 1.0 The Extensible HyperText Markup Language (Second Edition) (Kolme versiota: Strict - Transitional - Frameset) - Modularization of XHTML - XHTML Module-based XHTML - XHTML Basic - Suositus "XHTML 2.0" kehitteillä Huom! (X)HTML on vain julkaisuformaatti ja hyvin rajoittunut sellainen 49

12 3.12 Standardit, käytännöt ja perustason määrittely Standardi ei (yleensä) ole laki Historiallisesti esim. Web-standardien ja selainten (tms. prosessorien) kehitystyö on osoittanut että standardien käyttöönotto vaihtelee suuresti - "ellei laki pakota, markkinat ohjaavat" Standardien asettajat (ja työtä seuraavat sidosryhmät) saattavat projisoida standardeihin myös toiveita tai (yltiö)optimistisia odotuksia... Käytännössä tämä tarkoittaa esim. sitä että - kaikkia HTML & CSS -piirteitä ei toteuta yksikään selain -...kaikkia saavutettavuusohjeiden piirteitä ei yksinkertaisesti voi toteuttaa Saavutettavan palvelun tekninen toteutus on ilmeisesti sitä helpompaa mitä tarkemmin perustasosta (baseline) voidaan sopia 50

13 3.13 XHTML Basic, se pieni & järkevä XHTML-sanasto XHTML Basic määrittelee HTML:n kuvailevan ytimen Rajaus ja moduulijako on hyödyllinen, vaikkei kirjoittaisi varsinaisesti XHTML Basic - dokumentteja Jatkossa XHTML kehittynee entistä selvemmin juuri moduulien suuntaan - yhdisteltävyys ja profilointi - XML-tekniikoiden hyödyntäminen 51

14 3.14 Tärkeää: dokumenttien ja tiedon korrekti rakenne Koska tietokoneet eivät ymmärrä sisältöjä, niiden käsittelemien tietorakenteiden tulee olla rakenteeltaan täsmälleen määriteltyjä (X)HTML-dokumentin validoimisella tarkoitetaan testiä jossa valitun dokumentin rakenteen oikeellisuus selvitetään vertaamalla sitä (X)HTMLdokumentin tyyppimäärittelyyn ("malli tai muotti") Huom #1. Validius ei takaa että - dokumentti olisi sisällöllisesti mielekäs, tai että - dokumentti olisi saavutettava...koska dokumenttien rakenteella ja esim. tekstisisällöllä (merkkidata) on validiuden puitteissa varsin runsaasti liikkumavaraa (esim. kieli) Dokumentin tietojen järkevyys on siis tarkistettava muuten - Huom. #2 validointi on abstrakti XML-prosessi sopiva sovellusta ymmärtävä apuohjelma voi kuitenkin tukea myös sisällön tarkastamista 52

15 3.15 HTML-dokumentin ulkoasu? Rakenteisen dokumentin perusidea: - HTML-dokumentin rakenne kuvailee dokumentin tietosisällön -...jonka ulkoasun ja toiminnallisuuden (tai esitystavan!) sovellus päättää (esim. selain) Esim. XHTML: - tiedon esitysrakenne: otsikot ja kappaleet - toiminnallisuus: linkit ja lomakkeet - yhteydet muihin dokumentteihin: kuvat, objektit, yms. (HTML ~ Webin liimakieli) Muista puhesyntetisaattoriesimerkki! 53

16 3.16 Esimerkki: XHTML & CSS XHTML-dokumentin esitystapa voidaan ohjeistaa esim. CSS-tyyliohjeen avulla (Cascading Style Sheet): body { background: yellow; /* Pohja */ font-family: "Arial", sans-serif; color: rgb(0,0,50); } p { text-align:right; } p a { background: white; font-size: 150%; } a:active { background: black; color: white; } <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" " <html xmlns=" xml:lang="en" lang="en"> <head> <title>virtual Library</title> <link rel="stylesheet" type="text/css" href="pc-yell.css"/></head> <body> <p>check <a href=" </body> </html> <!-- Mod. --> 54

17 3.17 HTML-dokumentin ulkoasu ja tyylit, huomioita HTML-dokumentin esitystapa voidaan siis ohjeistaa esim. ns. tyylin (stylesheet) avulla CSS-tyyli voidaan päällekirjoittaa sovelluksessa, ts. esim. selain voi päättää tulkitako CSS-tyyliä vai ei (ja miltä osin) Tyyli kertoo miten rakenteinen dokumentti esitetään valitussa mediassa - tyyliohje määrittelee formatointiobjektit sekä näiden attribuutit (abstrakti käsite!) - yleisessä tapauksessa tyyliohje on tietokoneohjelma joka voi tehdä rakenteisella dokumentilla "mitä tahansa" Myös CSS-tieto pitää validoida 55

18 3.18 Cascading Style Sheets, ja esitystavan idea CSS jäsentää rakenteisen dokumentin tarjoten formatointimallin (tai malleja) johon sisältöä formatoidaan Visuaalinen formatointimalli: Viewport, block (display), property Yleisemmin, CSS-formatointiominaisuudet jaotellaan mediatyypeittäin: - all, aural, braille, embossed, handheld, print, projection, screen, tty, tv CSS määrittelee seuraava mediaryhmät: - continuous tai paged; visual, aural tai tactile; grid tai bitmap; interactive tai static; all 56

19 3.19 CSS, taulukot ja tuotettu sisältö CSS osaa (periaatteessa) jäsentää rakenteisen dokumentin myös taulukkona (a la HTML 4) Vastaavasti elementtien formatoinnin yhteydessä tulosdokumenttiin voidaan liittää myös esim. numerointitietoja ja vakiotekstiä Em. ominaisuuksien hyödyntäminen on kuitenkin sovelluksissa pulmallista, johtuen esim. selaintoteutusten vajavaisuuksista Vastaavasti ääniselainominaisuuksia yms. ei toistaiseksi ole yleisesti toteutettu (kehitystyötä: Voice Browser) CSS-suosituksen kehityskaari: CSS 1.0, , 3 ( moduulit) 57

20 3.20 Standardit tyylikielet, tyylikieli ja tieto Tyyliohjeita silmälläpitäen on kehitetty omia standardejaan: esim. XHTMLdokumentti voidaan esittää useilla eri tekniikoilla: - esim. CSS (Visual, Aural, Paged Media, Print, TV,...), XSL (XSLT, XSL-FO), mallikielet,... Käytännössä tyyliohje voi myös sisältää osan dokumentin välittämästä informaatiosta - Esim. XSL-tyyli voi olla funktionaalinen kuvaus: T:XHTML XHTML - esim. rakenne-elementtien asemointi, vakiotekstit, sivun ylläpitäjän tiedot, päivämäärä, kappaleiden numerointi, jne. - käytännössä esim. verkkopalvelun navigoinnin käyttöliittymä (linkit ja nappulat) tuotetaan tyypillisesti tyyliohjeen tai mallipohjan (template) avulla (yleensä "dynaamisesti", ylläpidollisista syistä) 58

21 3.21 Pieni sovellusesimerkki: Opettajan käyntikortti Halutaan esittää seuraavat tiedot verkossa"? Opettajan käyntikortti: Ossi Nykänen Tampereen teknillinen yliopisto, Matematiikan laitos, Hypermedialaboratorio Sähköposti: Huone: TD303 Opetusala: Hypermedia Opintojaksot: saavutettavuus, rakenteiset dokumentit,... Miten käytännössä? (Entäpä jos muille opettajille tehtäisiin vastaavat?) 59

22 3.22 Toteutustapa #1: Staattinen sivu käsityönä Suoraviivaisin tapa on kirjoittaa sovellus käsin tai sopivalla WWW-editorilla sivu sivulta (edistynyt tuotantoympäristö voi myös sisältää mallipohjia tms.) Perusidea: Tuotetaan (X)HTML-koodia esim. tekstieditorilla (esim. Grimson) Kysymyksiä: - Kuinka paljon sisältöä on, onnistuuko tuotanto ja ylläpito käsin? - Osataanko kaikki suunnitella ennen käyttökokeita? (Saavutettavuus?) Hyviä ja huonoja puolia: - Nopeasti alkuun mutta sovellus heikosti hallittavissa volyymin kasvaessa - Kaikki sovelluksen piirteet periaatteessa täysin räätälöitävissä, mutta esim. resurssisyistä johtuen, sovellus rämettyy helposti (esim. päivitykset ja versiointi, korjaukset, systemaattiset muutokset) - Tiedon esitystapa pitää käytännössä suunnitella täysin valmiiksi ennen toteutusta, täysin staattinen toteutus 60

23 3.23 Ettei totuus unohtuisi: verkkosivuista verkkopalveluun Verkkopalvelun toteuttamisessa on poikkeuksetta kaksi näkökulmaa: - sovellus toimii loppukäyttäjän näkökulmasta ( saavutettavuus ja käyttökelpoisuus) - toteutus- ja ylläpitokustannukset ovat järkeviä ( tuotantotyön menetelmät) Käytännössä verkkopalvelu on myös aina osa suurempaa kokonaisuutta, mistä seuraa omia reunaehtojaan (erit. tekn. tuotannon ja ylläpidon skaalautuvuus ja palvelutuotanto sisällön osalta) Toiminta verkossa Verkkopalvelu Verkkopalvelun tuottaminen Toiminta verkon takana (lue: sisältö) Taustaorganisaation palvelu Taustaorganisaation palvelutuotanto 61

24 3.24 Palvelutuotanto (RUP-jäsennys) ja saavutettavuus Development process (recursive step) Inception - rationale - scope - success criteria Elaboration - requirements - analysis & design - baseline architecture - construction plan Construction Transition - testing, tuning, training "Kaikkien muutostöiden hinta" nousee tuotantoprojektin edetessä Jos haluamme optimoida resurssien käytön ja maksimoida lopputuloksen: - saavutettavuus (WAI-ohjeet) tulee selkeästi ottaa jo määrittelyssä huomioon yhtenä tavoitteena muiden mukana (myös ylläpidon osalta) - suunnittelussa on huomioitava sekä WAI-ohjeet että WAI-tekniikat (reunaehdot ja rajoitteet) - perustaso ja testaamisen mittarit selvitetään jo aluksi 62

25 3.25 Verkkopalvelun tyypillinen suunnittelu Harva palvelu koostuu yhdestä sivusta. Verkkopalvelu jäsennetään usein (näkymältään) puumaiseksi rakenteeksi osioittain tai toiminnoittain (ylläpidon ja ymmärrettävyyden takia). Tulos: - palvelulla on tietty yleisjäsennys ja esim. hakutoiminto ( "navigointi") - asiasisältö (esim. aihealueittain) välittyy sivupohjien osoittaman jäsennyksen keinoin ( "viestiminen") - palvelu sisältää dynaamisia osia: palvelun jäsennys, esitystapa, sisältö tai toiminnallisuus saattaa vaihdella tai muuttua ( "vuorovaikutus") Uutiset Ohjelmoitava palvelualusta <?...?> Etusivu Artikkelit Uutiset Artikkelit Ryhmätyö... Ryhmätyö <?...?> <?...?> <?...?> 63

26 3.26 Tuotantotyön laskuoppia (mihin resurssit menevät?) Miksi palvelutuotannon mekaaninen hallittavuus on tärkeää? Triviaali esimerkki: palveluorganisaation yksinkertainen verkkopalvelu jossa työntekijöiden käyntikortit, tehtäväkuvaukset ja organisaation yleisinfo - N työntekijää, M tehtävää, kukin hoitaa T tehtävää, yleisinfossa etusivu, ohje, tehtäväkuvaukset ja sivukartta (sisällysluettelo), ts. 3 perussivua Peruskoulun laskuoppia, arvioidaan alarajoja (esim. N=5, M=15, T=4): - palvelussa on N+M+3 sivua tms. (23) - kunkin työntekijän sivulla on 1+T linkkiä (4), tehtävissä 1+N*T/M linkkiä (~2.3) ja sivukartassa N+M+2 linkkiä (22) - palvelussa on N*(1+T) + M*(1+N*T/M) + (N+M+2) linkkiä (127) - laskuissa ei ole mukana murupolkuja, hakutoimintoa, jne. (!) Tuotannon resursointi (versiointi ja muutokset?), ylläpito (sisällön eheys ja virheettömyys?),...mihin aikaa jää? Jääkö saavutettavuustyölle? 64

27 3.27 Huomioita saavutettavuustyöstä Matkaketjun hengessä, saavutettavuuden tulisi tietenkin toteutua koko palvelun osalta; - "saavutettava verkkopalvelu" voi hyvin hyödytön ellei palvelun varsinainen sisältö ole saavutettavissa (riippuvuudet vrt. esim. transaktion vahvistaminen paperikirjeellä johon allekirjoitus rapussa B2) Teknisen suunnittelun rakenteita kannattaa tietenkin hyödyntää saavutettavuustyössä: - verkkopalvelun arviointia ja kehittämistä kannattaa järkeistää arvioimalla saavutettavuutta sovelluksen verkkosivujen ja sivupohjien perusteella - (kognitiivinen) saavutettavuusarviointi kannattaa jakaa osiin myös esim. yleisrakenteen ja aihealueittaisen sisällön kesken, jne. Palvelutuotannon hyvä hallittavuus ("ohjelmoitavuus") mahdollistaa palvelun saavutettavuuden systemaattisen ja taloudellisen kehittämisen (profilointi?) 65

28 3.28 Toteutustapa #2: Dynaaminen sivu template-tekniikalla Sovelluksen "ohjelmoitavuus" paranee esim. mallipohjien käytöllä Tietomalli Lähdedokumentit Perusidea: sovellus tuotetaan dynaamisesti skriptikielen avulla (esim. PHP) Kysymyksiä: - Minne sivuilla näytettävä tieto talletetaan? (Tietokantaan) - Tarvitaanko dynaamisuutta? Riittääkö palvelimen teho? Mitä lisäarvoa ohjelmakoodilla haetaan? (Keksitäänkö pyörä uudelleen?) Hyviä ja huonoja puolia: - Nopeasti alkuun, lisäarvot suunnittelun myötä, volyymin kasvaessa työn painopiste siirtyy palvelun abstrahointiin ja esim. tietokantaohjelmointiin - Sovelluksen piirteet räätälöitävissä, myös vuorovaikutteisuus (yleisessä tapauksessa sivupohja-ajattelu on vain esim. ohjelmistonäkymä [view]) 66

29 3.29 Tuotannon näkökulma: (X)HTML on julkaisuformaatti Vaikka HTML-dokumentteja voi kirjoittaa suoraan tekstieditorilla, laajemmat sivustot tuotetaan hallittuun sisällöntuotantoprosessiin nojautuen: - sisältö kuvataan mediariippumattomasti sopivalla XMLsanastolla (+mediaobjektit) - kutakin julkaisumediaa (esim. HTML) kohti kirjoitetaan formatointiohje(lma tai tyyli) - käsikirjoitus formatoidaan kunkin median mukaisesti julkaisuprosessin yhteydessä ( monikanavajulkaisu) - jälkikäsittelyä pyritään välttämään, ylläpito, versiointi jne. hoidetaan keskitetysti 67

30 3.30 Monikanavajulkaisun perusidea Keskitetty ja hallittu sisällöntuotanto ja ylläpito, mekaaninen julkaisu Voi sisältää myös interaktiivisia osia yms. (Multi-Channel Publishing, Single Sourcing,..) XHTML käsikirjoitus Mediaobjektit SMIL XML 1.0 SVG PNG XLink XQuery XSL/FO XSLT XSLT CSS PDF CSS Sovellus #1 Sovellus #2 Sovellus #3 68

31 3.31 Toteutustapa #3: Sivu julkaisuprosessin tuloksena Suunnitelmallisempi lähestymistapa on mallintaa sovelluksen tiedot ja tietojen julkaisuprosessi Tietomalli Lähdedokumentit formatointi Tulosdokumentit Idea: Mallinnetaan data ja määritellään datan esitystavat Kysymyksiä: - Miten käsikirjoituksen (lähdedokumentin) tai tietokannan tiedot valitaan? - Onko sovellus tarpeeksi laaja jotta systemaattisen lähestymistavan edut realisoituvat? Hyviä ja huonoja puolia: - Työ alkaa selkeällä suunnitteluvaiheella, sovelluksen piirteet keskitetysti hallittavissa, mutta vuorovaikutteisuuden toteuttaminen edellyttää yhä esim. mallipohjatekniikoita, "ei räätälöintiä, geneerinen ratkaisu" 69

32 3.32 Saavutettavuusohjeistus vs. tekniikan mahdollisuudet Verkkopalvelun toteuttamisen menetelmät asettavat esim. verkkosisällön saavutettavuusohjeistuksen oikeaan perspektiiviin: - periaatteelliset mahdollisuudet (menetelmät, tekniikat, laitteet) - käytännölliset rajoitukset (tuotannon optimointi, mainstreaming, inhorealismi esim. sisällön ja ylläpidon rämettymisen suhteen, jne.) Normatiivinen verkkosisällön saavutettavuusohjeistus on pitkälti kirjoitettu "toteutustavan #1 hengessä" -...koska standardoinnin näkökulmasta rajaus on perusteltu -...mutta toteuttajan (ja arvioijan) pitää ottaa kantaa prosesseihin (ts. WAI-mittaristoa tarvitaan mutta se ei vielä yksin riitä) 70

33 3.33 "Tuotantoesimerkkien" rakenne ja viittaukset (1/2) Tietomalli ja tiedon esitystapa Käsityön määrä ja laatu Palvelinpään vaatimukset Saavutettavuusohjeistuksen ala! #1: Käsityö ope-kkortti.html ope-kkortti.css #2: Template-tekniikka ope-kkortti.css ope-kkortti-tiedot.txt ope-kkortti.php ope-kkortti_phpfunc.php 71

34 3.34 "Tuotantoesimerkkien" rakenne ja viittaukset (2/2) #3: (Monikanavainen) julkaisuprosessi ja julkaisuputket (nyt kaikki Web-sivuja) ope-kkortti.css ope-kkortti-tiedot.xml teacher-single-html.xsl out.html teacher-all-html.xsl out2.html teacher-table-html.xsl out3.html teacher-single-php.xsl out4.php ope-kkortti_phpfunc.php... 72

35 3.35 Jonosta (teksti) avaruuteen (grafiikka): SVG XHTML on "vain eräs" XML-tekstiformaatti Samalla perustekniikalla (XML) voidaan kuitenkin kuvailla (tai prosessoida) mitä tahansa tietoa - "yleisesti käytössä olevia" XML-tekstiformaatteja on satoja; "kuka tahansa" voi kehittää niitä lisää (mutta hyvän tekeminen...) Tyyppiesimerkki hyödyllisestä graafisten objektien (ja animaatioiden, yms.) kuvailuformaatista on SVG (Scalable Vector Graphics) Myös SVG-grafiikan saavutettavuuteen voi kiinnittää huomiota - käytännössä: objektirakenteen miettiminen, tekstivastineiden liittäminen objekteihin Kuvat: I. Herman 73

36 3.36 SVG-dokumentin rakenne SVG-dokumentti on kuten XHTMLdokumentti, mutta XHTML-sanaston ja hypertekstin yms. sijaan puhuu SVG-sanaston avulla grafiikasta, filttereistä, jne. <?xml version="1.0" encoding="iso " standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" " <svg width="12cm" height="4cm" viewbox=" " xmlns=" version="1.1"> <ellipse cx="600" cy="200" rx="550" ry="175" fill="yellow" stroke="blue" stroke-width="20"/> <rect x="1" y="1" width="1198" height="398" fill="none" stroke="blue" stroke-width="2" /> <polygon fill="red" stroke="blue" stroke-width="10" points="350,75 379, , , , , , , , ,161" /> <polygon fill="lime" stroke="blue" stroke-width="10" points="850,75 958, , , , ,137.5" /> <text x="470" y="240" font-size="70">tekstiä</text> </svg> 74

37 3.37 Skriptatut dokumentit XML-sovellukset tarjoavat tyypillisesti mahdollisuuden liittää dokumentteihin (esim. XHTML tai SVG) myös tapahtumaohjattuja selaimessa ajettavia skriptejä (esim. Ecmascript [Javascript], VBScript) - esim. hiiren liike, napinpainallus, ajastettu tapahtuma DOM-manipulointi Yleensä skriptien käyttö heikentää dokumenttien saavutettavuutta (...koska skripti voi toimia "selaimen käyttöliittymän ohi" määrittelemättömyys) Skriptien käytölle on hyvin huonoja, huonoja ja melko hyviä perusteita - hyvin huono syy on turha erikoistehoste, esim. näyttöelementin liikuttelu - melko huono syy voi olla esim. käyttöliittymän hallittu laajentaminen, esim. fiksu statuskenttä (dokumentin loogista rakennetta rikkomatta) - ok- peruste on rajattu sovellus, jonka selain ja käyttäjäkunta on tarkkaan tunnettu (esim. Intranet); joskus käytetään myös esim. syötteiden esitarkistukseen, mutta vaatisi miettimistä (...mutta XForms) 75

38 3.38 Avaruudesta aikaan Saavutettavuuden luonne hieman muuttuu kun tarkastellaan ajassa muuttuvia esityksiä -...ts. kun "poistutaan kuolleen tekstin maailmasta" vrt. SVG-esimerkki "reversi"... Yleisessä tapauksessa käyttöliittymä voi koostua erilaisista mediaelementeistä jotka ovat aikariippuvaisia Saavutettavuus tarkoittaa tällöin - vaihtoehtoisia tiedon esitystapoja (vrt. tv-ohjelman tai elokuvan tekstitys huonokuuloiselle suomenkieliselle henkilölle vs. tekstitys kuurolle suomenkieliselle henkilölle) ja - mahdollisuutta "pysäyttää aika" (esim. näkövammainen henkilö tai henkilö joka on hidas lukemaan tai haluaa pysäyttää esityksen esim. taustatietojen haun ajaksi) 76

39 3.39 Synkronoitu multimedia ja SMIL Kuva: CSC Standardin synkronoidun multimedian koostamiseen määrittelee esim. SMIL (Synchronized Multimedia Integration Language) Edellyttää yleensä erillistä soitto-ohjelmaa (esim. RealPlayer) Myös SMIL sisältää saavutettavuuspiirteitä - vaihtoehtoinen sisältö, hakemistot, mutta käytännössä soittoohjelman (käyttöliittymän) saavutettavuus sinänsä voi muodostua esteeksi 77

40 3.40 SMIL-dokumentin rakenne <?xml version="1.0"?> <!DOCTYPE smil PUBLIC "-//W3C//DTD SMIL 2.0//EN" " <smil xmlns=" xml:lang="en" title="picture-in-picture Television"> <head> <layout> <toplayout width="320px" height="240px"> <region id="main-video" left="0%" top="0%" width="100%" height="100%"> <region id="corner-video" left="67%" top="67%" width="33%" height="33%" fit="scale" soundlevel="0%"/> </region> </toplayout> </layout> </head> <body> <par> <video id="chameleon-video" src="chameleon.mpg" alt="an animated chameleon" region="main-video"/> <video id="earthquake-video" src="earthquake.mpg" alt="san Fransisco earthquake aftermath" region="corner-video" end="chameleon-video.end"/> </par> </body></smil> Kuva ja esimerkki: C. Forno 78

41 3.41 Lopuksi: tekniset menetelmät ja saavutettavuustyö Käyttäjien, käyttötapojen ja käyttökelpoisten sovellusten tuntemus on saavutettavuustyön perusta, mutta se ei vielä yksin riitä: tarvitaan suunnitteluosaamista koska - kyse on myös esim. verkkosovellusten menetelmien tuntemisesta teknisellä tasolla (esim. monikanavajulkaisu) ja esim. XMLtekstiformaattien teknisten saav.ominaisuuksien osaamisesta (esim. SVG-dokumentin suunnittelu tekstivastineiden näkökulmasta)...muuten käy niin että juututaan puhumaan saavutettavuudesta yläkäsitteiden tasolla, tavalla, jolla ei ole merkittäviä vaikutuksia (verkko)sovelluksen loppukäyttäjän näkökulmasta -...eikä osata esim. arvioida tuotantotyön todellisia kustannuksia Standardoitujen XML-tekstiformaattien ja esim. näiden selaintoteutusten asteittainen kehittyminen (eri tahdissa) asettavat erittäin suuria haasteita käytännön saavutettavuustyölle 79

42 3.42 Rajaus (tenttilukijoille tiedoksi) Keskeistä on nyt ymmärtää verkkosovellusten teknisen perustan ja tuotantotyön, sekä saavutettavuusohjeistuksen välinen suhde (muuten saav. jää yläkäsitteiden tasolla ohueksi) Itse saavutettavuusohjeet eivät kuitenkaan juuri opeta menetelmätason osaamista (koska ne on rajattu lopputuloksen arviointiin) - vrt. XHTML-perhe vs. HTML-perusteet ("kotisivun osaavat kaikki tehdä") Tentissä ei oleteta/vaadita seuraavien tekniikoiden yksityiskohtaista hallintaa - PHP, XML/XSL/XSLT, XForms, SVG, SMIL, tiedon formaali mallinnus...mutta koko homman idea ja riippuvuudet olisi syytä ymmärtää Asioita opetetaan tarkemmin osana esim. opintojaksoja HM ohjelmointi, Rakenteiset dokumentit ja Rakenteisten dokumenttien jatkokurssi 80