W3C har publisert ekstra mange nye spesifikasjoner og webstandarden de siste to ukene. (Foto: W3C)

W3C-spesifikasjoner

Flere spennende webteknologier

Økt sikkerhet og tilgjengelighet i spesifikasjoner fra W3C.

Det er ikke bare funksjonsfriske som bruker datamaskiner i alle størrelser. Også mennesker med ulike funksjonshemminger og spesielle behov har stor nytte av datamaskiner, i alle fall dersom det tas hensyn til at ikke alle har like gode sanser eller bevegelighet som brukere flest.

Mobil tilgjengelighet

Dette gjelder selvfølgelig også websider og -applikasjoner, og det finnes webstandarder og retningslinjer, Web Content Accessibility Guidelines (WCAG), som beskriver hvordan man kan oppnå bedre tilgjengelighet på weben. Men weben er i stadig utvikling, noe som også påvirker tilgjengeligheten.

Et resultat av dette er et første utlast til hvordan WCAG 2.0 og andre W3C/WAI-retningslinjer kan brukes sammen med mobilt innhold, inkludert både web- og systemspesifikke applikasjoner. Det er en kjent sak at stadig mer webinnhold konsumeres med mobile enheter med relativt liten skjerm. Forhold som tas opp i utkastet inkluderer derfor skjermstørrelse, zooming, kontrast, tastaturkontroll, berøringsfunksjonalitet og skjermretning.

Ny standard #1

Samtidig med denne utgivelsen, kunngjorde W3C også at flere andre, relaterte nyheter. Den ene er at HTML5 Image Description Extension er gjort til en W3C-standard. Dette er en svært spesiell spesifikasjon som faktisk tillater at en hyperlenke eksisterer innen i en annen, i forbindelse med bilder på en webside. Hensikten er at man på en på en egen webside skal kunne tilby en mer utførlig beskrivelse av bildet enn det alt-attributtet til bildet er ment å tilby. Dette er ikke bare ment for synshemmede, men også for systemer med begrenset, visuell gjenkjenningsevne.

W3C offentliggjorde i går for første gang også et arbeidsutkast til SVG Accessibility API Mappings 1.0. Dette beskriver hvordan nettlesere kan overføre SVG-tagger (Scalable Vector Graphics) til programmeringsgrensesnitt for økt tilgjengelighet, som brukes til å kommunisere semantisk informasjon om brukergrensesnittet til hjelpemiddelteknologi som brukes av funksjonshemmede. I dag brukes dette av blant annet skjermlesere til å hjelpe synshemmede med å avgjøre om et element i brukergrensesnittet er for eksempel en meny, en tekstfelt eller liste med ulike valgmuligheter.

Ny standard #2

W3C publiserte i går også spesifikasjonen til den helt nye, offisielle webstandarden Linked Data Platform 1.0. Spesifikasjonen beskriver bruken av HTTP for å aksessere, oppdatere, opprette og slette ressurser på servere som fremviser sine ressurser som «Linked Data». Weboppfinneren Tim Berners-Lee har beskrevet hva som menes med lenkede data, i motsetning til lenkede hypertekst-dokumenter, på denne siden.

Ny funksjonalitet

W3C publiserte i forrige uke flere helt ferske utkast til kommende webspesifikasjoner som skal kunne gi webplattformen utvidet funksjonalitet. Media Capture from DOM Elements definerer hvordan en mediestrøm fra elementer som canvas, audio og video kan fanges inn og prosesseres ved hjelp av ulike programmeringsgrensesnitt, slik som WebRTC og Web Audio. Utkastet er basert på eksperimentell funksjonalitet som allerede tilbys i Firefox.

Det første offentlige utkastet til Server Timing-spesifikasjonen beskriver et nytt header-felt og et JavaScript-grensesnitt for nøyaktig måling av ytelseskarakteristikkene til webapplikasjoner, noe som skal kunne gjøre det enklere å finne årsakene til hvorfor en syklus med forespørsel og respons tar lang tid. Denne informasjonen kan gjøre det mulig for utviklerne å optimalisere disse syklusene.

Presentasjoner

Et første utkast til Presentation API ble også utgitt i forrige uke. Dette tilbyr et programmeringsgrensesnitt som skal gjøre sekundære skjermer tilgjengelige for webapplikasjoner. Det å kunne vise innhold på en større skjerm enn den som er integrert i brukerenheten, er ofte viktig dersom innhold skal vises til en gruppe med personer. Presentation API skal derfor tilby støtte for eksterne skjermer som er tilknyttet brukerenheten ved hjelp av kablet eller trådløs teknologi. Dette inkluder både kabelstandarder som HDMI og DVI, og trådløse teknologier som MiraCast, Chromecast, DLNA og AirPlay.

Den nye spesifikasjonen beskriver hvordan det kan utveksles meldinger mellom en «anmodende» webside og presentasjonssiden som vises på den sekundære skjermen. Begge sider kan gjengis ved hjelp av den samme nettleseren («User Agent»), men i stedet for å vise begge i et vindu på den samme enheten, utnyttes funksjonalitet som tilbys av enhetens operativsystem til å rute visningen av den ene websiden til en ekstern skjerm.

Mer sikkerhet

W3C har nylig også publisert to nye spesifikasjonsutkast knyttet til sikkerhet. Det ene, Content Security Policy Pinning, definerer en mekanisme som webutviklere kan bruke til å manipulere sikkerhetsegenskapene til en gitt ressurs, noe som skal gjøre det mulig å redusere risikoen for å mange tyder angrep basert på injisering av innhold.

Spesifikasjonsutkastet Upgrade Insecure Requests skal kunne bidra til økt brukersikkerhet på nettsteder med mye gammelt og hardkodet innhold. La oss ta utgangspunkt i et slikt nettsted som nå ønsker å tilby alt innhold ved hjelp av krypterte HTTPS i stedet for ikke-krypterte HTTP. I mange av de eldre artiklene som nettstedet i dag tilbyr, er lenkene til bilder og annet integrert innhold oppgitt med absolutt URL, med HTTP som skjemanavn. Dersom selve websiden, men ikke alt innholdet, lastes med HTTPS, vil man få tilfeller av blandet innhold («mixed content»), og dette er noe som «mislikes» av flere av dagens nettlesere. Enten blokkeres det usikre innholdet, eller så blir brukeren vist advarsler om at ikke alt innhold er kryptert.

For et nettsted med stort arkiv, vil det kunne være en stor og kanskje usikker jobb å endre alle de hardkodede URL-ene fra HTTP til HTTPS.

Det er her den nye spesifikasjonen kommer inn. Den beskriver et headerfelt som forteller nettleseren at den skal laste bilder og annet innskutt innhold på websidene ved hjelp av HTTPS, uavhengig av hva som er oppgitt URL-ene i HTML-dokumentene. I stedet må man bare sørge for at webserveren alltid sender denne headerinformasjonen.

 

Til toppen