Share
Jag hade det stora nöjet att leverera den avslutande keynoten på Responsive Day Out 3: Den slutliga brytpunkten. Hölls i Brighton, Storbritannien, den 19 juni 2015, konferensen var en samling av designers och utvecklare som delar sina arbetsflödesstrategier, tekniker och erfarenheter med responsiva webbdesign.
Här är vad jag hade att säga.
Idag har en fantastisk turné i världen av lyhörd design. Vi har sett hur vi laddar upp våra arbetsflöden och processer. Vi har lärt oss nya sätt att förbättra tillgängligheten för våra produkter. Vi har kämpat med moderna CSS- och HTML-funktioner som hjälper oss att omfamna de enormt varierande bildstorlekarna som virvlar runt och virvlar runt oss.
Vi har undersökt framtiden för modulär kod och webbläsares kapacitet att arbeta utan nätverksanslutning. Och vi har även tagit en resa in i den möjliga framtiden för var webben skulle gå.
Vi har kommit långt sedan Ethans artikel, fluidnät, flexibla medier och mediafrågor. Dessa tre principer sådde ett frö som har vuxit och blomstrade som vi har kommit för att bättre förstå konsekvenserna av enhetsspridning. Vi har sett att webben kan gå någonstans och göra ganska mycket vad som helst.
Jag skulle hävda att "Responsive Web Design" var den första artikeln som verkligen lyckades fånga de begrepp som John Allsopp hade diskuterat så många år tidigare i "A Dao of Web Design" och destillerade dem till något som design- och utvecklingssamhället verkligen kunde sjunka deras tänder in Det gav ett konkret exempel på webbens förmåga att böja och forma sig i vilken form det var nödvändigt att ta på sig.
Det var första gången många designers hade kommit överens med idén att "erfarenhet" inte var någon monolitisk sak.
Visst, många av oss i webbstandardgemenskapen hade pratat pratstunden och gick på promenad med avseende på progressiv förbättring. Och vi fick omvandlar, men framstegen var långsam. Ethan demonstrerade - direkt och succinkt - vad den progressiva förbättringen av visuell design skulle kunna se ut.
Att ge en identisk upplevelse för varje människa som försöker komma åt våra webbplatser skulle vara omöjligt. Det finns helt enkelt alltför många faktorer att överväga. Vi har skärmstorlek, skärmdensitet, CPU-hastighet, mängd RAM, sensor tillgänglighet, funktion tillgänglighet, gränssnittsmetoder ... andas ... operativsystemtyp, operativsystemversion, webbläsartyp, webbläsareversion, insticksprogram installerade, nätverkshastighet, nätverksfördröjning, nätverkstoppning, brandväggar, proxies, routrar och förmodligen ett dussin andra faktorer är mitt sinne oförmögen att plocka mitt i virvelvind av tekniska överväganden.
Och det överväger inte ens våra användare.
När det gäller de människor vi behöver för att nå vårt arbete för att faktiskt betyda, måste vi överväga läskunnighet, läsa akumen, nivå av domänkunskap, kognitiva funktionsnedsättningar som inlärningssvårigheter och dyslexi, problem med uppmärksamhetsbrister, miljöavstörningar, synnedgång, hörselskador, nedsatt motorförmåga, hur mycket de förstår hur man använder sin enhet, hur mycket de förstår hur man använder webbläsaren, hur välkända i vanliga webbkonventioner de är och en massa andra "mänskliga faktorer".
Varje person är annorlunda och alla kommer på webben med sin egen uppsättning specialbehov. Vissa är alltid med dem, blinthet till exempel. Andra är övergående, som att bryta din mousing arm. Fortfarande andra är rent situationella och beroende av vilken enhet du använder då och dess tekniska förmågor eller begränsningar.
Att försöka utarbeta en monolitisk erfarenhet för varje person att ha i varje sammanhang som anser att varje faktor skulle vara omöjlig. Och ändå hade Sir Tim Berners-Lee en vision för en webb som kunde gå någonstans. Var han galen?
Sir Tims vision för webben var att innehållet kunde skapas en gång och åtkomst från var som helst. Olika men relaterade bitar av "hypermedia" spridda över hela världen kunde kopplas till varandra via länkar. Dessutom skulle de kunna återvinnas av någon på en enhet som kan läsa HTML. Gratis.
I slutändan föreslog Sir Tim universell tillgänglighet.
För en stor del av oss är det en eftertanke att se till att våra webbplatser är tillgängliga. Vi pratar ett bra spel när det gäller "användarcentrerad" detta eller så, men behandlar ofta ordet "tillgänglighet" som en synonym för "skärmläsare". Det är så mycket mer än det. "Tillgänglighet" handlar om människor. Människor konsumerar innehåll och använder gränssnitt på många olika sätt, några liknande och vissa ganska olika för hur vi gör det.
Visst, personer med synskadade använder ofta en skärmläsare för att konsumera innehåll. Men de kan också använda en braille-touch-återkopplingsenhet eller en braille-skrivare. De brukar också använda ett tangentbord. Eller de kan använda en pekskärm i samklang med ljudsignaler. Eller de kan till och med använda en kamera för att tillåta dem att "läsa" innehåll via OCR och text till tal. Och ja, visuell nedsättning påverkar en anständig andel av befolkningen (särskilt när vi ålder), men det är bara en del av "tillgängligheten" pussel.
Kontrasten mellan text och bakgrund är en viktig faktor för att säkerställa att innehållet är läsbart i olika belysningssituationer. Färgval är en tillgänglighetsfråga.
Språket vi använder på våra webbplatser och i våra gränssnitt påverkar direkt hur enkelt det är för våra användare att förstå vad vi gör, de produkter vi erbjuder och varför det är viktigt. Det påverkar också hur vi får våra användare att känna sig själva, deras erfarenhet och våra företag. Språk är en tillgänglighetsfråga.
Storleken på våra webbsidor har en direkt effekt på hur lång tid våra sidor tar för att ladda ner, hur mycket det kostar våra kunder att komma åt dem, och (ibland) även om innehållet kan nås. Prestanda är en tillgänglighetsproblem.
Jag skulle kunna fortsätta, men jag är säker på att du får poängen.
Tillgänglighet handlar om att ge bra upplevelser för alla, oavsett fysisk eller mental förmåga, kön, ras eller språk. Det erkänner att vi alla har speciella behov - fysiska begränsningar, begränsningar av bandbredd, begränsningar av enheter - det kan kräva att vi upplever samma gränssnitt på olika sätt.
När jag till exempel besöker en webbplats på min telefon är jag visuellt begränsad av min skärmupplösning (speciellt om jag använder en webbläsare som uppmuntrar till zoomning) och jag är begränsad i min förmåga att interagera med knappar och länkar eftersom jag surfar med mina fingertoppar, vilka är större och mycket mindre noggranna än en muspekare.
På en pekskärm kan jag behöva erfarenheten vara något annorlunda, men jag måste fortfarande kunna göra vad som helst jag kom till platsen att göra. jag behöver en erfarenhet, men dessutom behöver jag lämplig erfarenhet.
Att fira verkligheten att erfarenheten inte behöver vara bara en sak kommer att hjälpa oss att nå fler personer med färre huvudvärk. Erfarenheten kan och bör utformas som ett kontinuum. Detta är en progressiv förbättring: Vi börjar med en baslinjeupplevelse som fungerar för alla - innehåll, riktiga länkar, först generationskontrollformer och formulär som faktiskt skickar till servern. Då bygger vi upp erfarenheten därifrån.
Din webbläsare stöder kontroller för HTML5-formulär? Bra! Du får ett bättre virtuellt tangentbord när du går och skriver in din e-postadress. Du kan använda CSS? Awesome, låt mig göra den läsupplevelsen bättre för dig. Åh, du kan hantera mediafrågor! Låt mig anpassa layouten så att de här linjelängderna är lite mer bekväma. Wow, stöder din webbläsare Ajax ?! Här, låt mig ladda in några teasers för relaterat innehåll som du kan hitta intressant.
Tänk dig att sitta ner i en restaurang, bara för att ha servitören omedelbart få dig en biff. Men du är vegetarian. Du frågar om de erbjuder något du kan äta och de svarar artigt: "Åh Jag är ledsen, kött är ett krav. Varför äter du inte bara kött? Det är enkelt! Du saknar verkligen lite smakrik mat." Ingen servitör som verkligen bryr sig om din upplevelse skulle göra det.
Och ändå verkar vi som en bransch - inte ha något problem att berätta för någon att de behöver byta webbläsare för att rymma oss. Det är bara fel. Vårt arbete är meningslöst utan användare. Vi borde böja över bakåt för att locka och behålla dem. Detta är kundtjänst 101.
Detta återkommer till Postels lag, som Jeremy ofta berättar om:
Var försiktig i vad du gör, var liberal i vad du accepterar från andra.
Vi måste vara lax när det gäller webbläsarsupport och inte göra för många (eller bättre än några) antaganden om vad vi kan skicka.
Självfallet är detta inte ett tillvägagångssätt som alla i vår bransch är redo att omfamna, så jag ska erbjuda ett annat citat jag kommer tillbaka till gång på gång ...
När något händer är det enda i din makt din inställning till det; du kan antingen acceptera det eller ångra det.
Vi kan inte styra världen, vi kan bara styra vår reaktion på det.
Nu förstår de som har samlat för den här sista Responsive Day Out (eller som följer med hemma) förmodligen detta mer än de flesta. Vi känner det ständiga bombardemanget för nya enheter, skärmstorlekar och funktioner. Det enda sättet jag har hittat för att hantera allt detta är att acceptera det, omfamna mångfalden och se enhets- och webbläsarspridning som en funktion, inte en bugg.
Det är upp till oss att utbilda dem som finns omkring oss som har - oavsiktligt eller avsiktligt - inte accepterat att mångfald är den verklighet vi lever i och saker kommer bara att bli galenare. Att begrava våra huvuden i sanden är inte ett alternativ.
När jag försöker hjälpa folk att förstå och omfamna mångfald, når jag ofta för en av mina favorit tänkande övningar från John Rawls.
Rawls var en filosof som brukade driva ett socialt experiment med studenter, kyrkogrupper och liknande.
I experimentet fick deltagarna skapa sitt idealiska samhälle. Det kan följa någon filosofi: Det kan vara en monarki eller demokrati eller anarki. Det kan vara kapitalistiskt eller socialistiskt. Folket i detta experiment hade frihet att kontrollera absolut alla aspekter av samhället ... men då skulle han lägga till vredet: De kunde inte styra vilken ställning de ockuperade i det samhället.
Denna vridning är vad John Harsanyi-en tidig spelteoretiker-refererar till som "okunnighetens slöja". Vad Rawls fann, gång på gång, var att individer som deltog i experimentet skulle gravta mot att skapa de mest egalitära samhällena.
Det är meningsfullt: Vilket rationellt, självintresserat människa skulle behandla äldre, sjuka, människor av ett visst kön, ras, trosbekännelse eller färg dåligt om de kunde hitta sig i samma position när slöjan dras bort?
De saker vi gör för att tillgodose speciella behov betalar nu utdelning i framtiden. Titta på ramper.
De är ett klassiskt exempel på en tillgänglighetsfunktion för personer i rullstolar som också gynnar människor som inte är i dem: människor som bagar ihop, leveranstjänster tar tunga saker på dollies, föräldrar som driver barn (eller sina klädda hundar) i barnvagnar, en pendlare går sin cykel och den killen som bara föredrar att gå en mild lutning för att utnyttja den ansträngning som krävs för att montera ett steg.
När vi skapar alternativa vägar för att komma från punkt A till punkt B kan människor ta den som passar dem, oavsett om de är valbara eller nödvändiga. Och alla kan nå sina mål.
Vi har alla speciella behov. Några vi är födda med. Några vi utvecklar. Vissa är tillfälliga. Vissa har inget att göra med oss personligen, men är situationella eller rent beroende av den maskinvara vi använder, interaktionsmetoderna som vi har tillgång till, eller till och med hur snabbt vi kan få tillgång till Internet eller processdata.
Vad är responsiv webbdesign om, om inte tillgänglighet? Ja, dess grundläggande principer handlar om visuell design, men när det gäller den stora bilden handlar de om att ge bästa möjliga läsupplevelse.
Som utövare av responsiv design förstår vi fördelarna med att anpassa våra gränssnitt. Vi förstår fallbacks. Vi förstår hur man utformar robusta erfarenheter som arbetar under en mängd olika förhållanden. Varje dag breddar vi tillgängligheten för våra produkter.
Dessa färdigheter kommer att göra oss ovärderliga eftersom tekniken fortsätter att erbjuda nya sätt att konsumera och interagera med våra webbplatser.
Vi börjar precis att doppa eller tåla, händer in i en värld av rörelsebaserade gestikala kontroller. Visst, vi har haft dem i två dimensioner på pekskärmar ett tag nu men tredimensionella rörelsesbaserade kontroller börjar bara dyka upp. Du kan se en demonstration av gestikala kontroller runt 41-sekundersmarkeringen i följande video:
Det första stora språket i den här riktningen var Kinect på Xbox 360 (och senare Windows). Med Kinect samverkar vi med datorn med hjälp av kroppsrörelser som att höja en hand (som får Kinect att uppmärksamma), skjuta vår hand framåt för att klicka / knacka och ta tag i att dra i duken i en viss riktning.
Kinect inledde en stor revolution när det gäller gränssnitt med datorer, men ur ett interaktionsperspektiv presenterar det liknande utmaningar som Wii controller och Sony PlayStation Move. Stora kroppsfunktioner som att höja din hand (eller en trollstyrenhet) kan vara tröttsam.
De är inte heller väldigt korrekta. Om du trodde att pekskärmens noggrannhet var ett problem, utgjorde handbevakningar som Kinect eller LEAP Motion ännu mer utmaning.
För att kunna hantera interaktioner så här (som vi för närvarande inte har möjlighet att upptäcka) måste vi vara medvetna om hur enkelt det är att klicka på interaktiva kontroller. Vi måste bestämma om våra knappar och länkar är tillräckligt stora och om det finns tillräckligt med utrymme mellan dem för att säkerställa att användarens avsikt är korrekt överförd till webbläsaren. Två specifikationer som kan hjälpa till med detta är Media Queries Level 4 och Pointer Events.
I Media Queries Level 4 blev vi i stånd att tillämpa stilregler till specifika interaktionssammanhang. Till exempel när vi har mycket noggrann kontroll över vår markör (som vid en pekare eller mus) eller mindre noggrann kontroll (som vid en pekskärm eller fysisk gest):
@media (pekare: grov) / * Mindre länkar och knappar är ok * / @media (pekare: grov) / * Större länkar och knappar är nog en bra idé * /
Självklart vill vi erbjuda en förnuftig standard när det gäller storlek och avstånd som backning för äldre webbläsare och enheter.
Vi har också möjlighet att bestämma om enheten kan sväva över ett element och kan justera gränssnittet i enlighet därmed.
@media (svängare: svängare) / * svängrelaterade interaktioner är A-OK * / @media (svängare: på begäran) / * svängrelaterade interaktioner är potentiellt svåra, kanske gör något annat istället * / @ media (svever: ingen) / * Ingen svängning möjlig :-( * /
Vi behöver fortfarande ta reda på hur bra allt detta slutar fungera på multimodala enheter som Surface tabletten, dock. Kommer designen att ändras när användaren växlar mellan ingångslägen? Borde det? För detta ändamål ger specifikationen också någon-pekaren och någon-hoverto, så att du kan fråga om huruvida några stödd interaktionsmetod uppfyller dina krav, men här är ett varningstecken från specifikationen:
Designa en sida som bygger på svängning eller korrekt pekning endast för att någon-hover eller någon-pekarenange att en inmatningsmekanism med dessa funktioner är tillgänglig, kommer sannolikt att leda till en dålig upplevelse.
Dessa alternativ för mediefrågor börjar rinna ut i Chrome, Mobile Safari och Microsoft Edge, så det är värt att ta en titt på dem.
Pointer Events är en annan spec som börjar få lite dragkraft. Det generaliserar interaktion till en enda händelse snarare än att tvinga oss till siloupplevelse i musdriven, pekdriven, pennstyrd (suck) kraftdriven och så vidare.
Vi kan diskret upptäcka stöd för Pointer Events ...
Accentsconagua
om (window.PointerEvent) window.addEventListener ("pointerdown", detectType, false); ... och hantera dem på samma sätt eller skapa grenar baserade på pointerType:
funktion detectType (händelse) switch (event.pointerType) case "mouse": / * musinmatning detekteras * / break; case "penna": / * penna / penna ingången detekteras * / break; fall "touch": / * peka in detekterat * / break; default: / * pointerType är tom (kunde inte detekteras) eller UA-specifik anpassad typ * /
Förutom att vi beaktar nivån av noggrannhet våra användare har samtidigt som de interagerar med våra skärmar, måste vi också överväga det potentiellt ökade avståndet där våra användare läser vårt innehåll.
För det ändamålet har jag experimenterat med visningsportbredden (vw) -enheten.
Jag har länge använt ems för layoutens maxbredd (så linjelängden är proportionell mot teckensnittstorleken). Jag använder också relativa teckensnittstorlekar. Med det som grunden kan jag använda en mediefråga som matchar maximal bredd och ställa in basstorlekstorleken vid vw ekvivalent vid max bredd.
kropp maxbredd: 64em; @ media skärm och (min bredd: 64em) kropp font-size: 1.5625vw; / * (1em / 64em) * 100 * /
Då kommer hela designen enkelt att zooma in layouten när den ses bortom den storleken.
Om du inte vill göra något på så sätt automatiskt kan du aktivera det med JavaScript på och av.
Saker blir ännu galen när du börjar faktor i enheter som HoloLens. Och nej, jag har inte fått spela med en ännu, men du kan se en bra demo på 1:27-märket på den här videon:
Men tanken på att kunna släppa en virtuell skärm på en viss yta ger några intressanta möjligheter som användare och några unika utmaningar som designer. HoloLens, naturligtvis, medför också gestkontrollen, så att redovisa en mängd olika typer av inmatning borde få oss ganska långt.
På samma sätt bör vi börja tänka på vilka erfarenheter som kan och ska se ut när vi bläddrar enbart med vår blick. Gaze tracking har sitt ursprung i tillgänglighetsutrymmet som ett sätt att tillhandahålla gränssnittskontroll till personer med begränsad eller ingen användning av sina händer. Traditionellt blickar spårningsvaran har varit flera tusen dollar och sätter den utom räckhåll för många människor, men det börjar förändras.
Under de senaste åren har beräkningsförmågan hos våra enheter ökat, eftersom hårdvarukostnaderna i samband med att stödja blicken har minskat dramatiskt. Om du tittar runt kan du se blicken följa med att flytta in i den offentliga sfären: Många smartphones och smartwatches kan känna igen när du tittar på dem (eller åtminstone de gör det ibland). Detta är bara ett kort steg bort från att veta var på skärmen du letar efter. Och nästan varje avancerad smartphone är nu utrustad med en framåtvänd kamera, vilket gör dem perfekta kandidater för att tillhandahålla denna interaktionsmetod.
Du kan se en bra demonstration av Sesame Phones ansiktsspårningsteknik från 18-sekundersmarkeringen i den här videon:
Sesamelefonen var utformad för att tillåta människor att använda en smartphone utan att använda sina händer. Det använder ansiktsspårning för att flytta en virtuell markör runt skärmen, så att användarna kan interagera med det underliggande operativsystemet såväl som enskilda applikationer. Den stöder tryck, svep och andra gester (via en snabbmeny) och är ganska imponerande i min erfarenhet. Teknik som detta gör det möjligt för personer som lider av MS, artrit, muskeldystrofi och mer att använda en smartphone och - viktigare för oss - surfa på nätet.
Ögonstammen och Fixational fungerar på samma sätt för att få ögonspårning till smartphones och tabletter. Ögonspårning liknar ansiktsspårning, men markören följer ditt fokus. Mikrovågor-blink, blink, etc.-låter dig interagera med enheten.
Även om de flesta blickspårningssystem efterliknar en mus och har justerbar känslighet, är noggrannheten av det som en pekdon inte fantastisk. När jag till exempel har använt Sesamelefonen har jag haft svårt att kontrollera huvudets position för att hålla markören kvar för att sväva och klicka på en knapp. Jag är säker på att detta skulle förbättras med övning, men det är säkert att säga att i en blickinteraktion skulle större, väl åtskilda och lättare riktade länkar och knappar vara en gudstjänst.
Hittills har jag fokuserat på interaktionsmetoder som underlättar navigering och konsumerar innehåll. Men hur är det med att fylla i ett formulär? Jag kan berätta för dig att skriva ett brev i brev till ett virtuellt tangentbord, med ditt ansikte, suger ...
Lyckligtvis är de flesta av dessa gestural-implementeringar kopplade till någon form av röstigenkänning. Kinect, till exempel, kommer att acceptera verbala kommandon för att navigera och utföra uppgifter som att fylla i formulär. Sesamelefonen stöder också röstkommandon för vissa grundläggande åtgärder, diktering av e-post och liknande.
Kombinerade med röst fungerar Kinects och Sesamas alternativa interaktionsmetoder väldigt bra. Men röstsamverkan kan också stå på egen hand.
De flesta av oss är bekanta med Apples Siri, Google Now och Microsofts Cortana. Dessa digitala assistenter är bra att hämta information från valda källor och göra andra assistent-saker som att beräkna ett tips och ställa in en påminnelse. När det gäller att interagera med webben, gör de dock inte ... än. Vi kan engagera dem, men de kan inte (nödvändigtvis) engagera sig med en webbsida.
Exponera informationen som lagras i våra webbsidor via semantisk HTML och strukturerad syntax som mikroformat, mikrodata och RDFa skall så småningom gör våra innehåll tillgängliga för dessa assistenter, men vi vet inte riktigt. Deras olika beslutsfattare har inte riktigt gett oss några anvisningar om hur man gör det och, som det står just nu, kan ingen av dem leta upp en webbsida och läsa den för dig. För att du behöver anropa en skärmläsare.
Varje företag erbjuder en första skärmsläsare. Och alla kan hjälpa dig att interagera med en sida, inklusive att hjälpa dig att fylla i formulär utan att behöva se sidan. Och ändå har dessa tekniker inte kopplats till motsvarande assistenter. Det kommer nog inte vara länge innan vi ser det hända.
När vi börjar överväga hur våra webbplatser kommer att upplevas i ett röstsammanhang blir läsbarheten hos våra webbsidor avgörande. Tydlig välskriven prosa och en logisk källorder är en absolut nödvändighet. Om våra sidor inte är meningsfulla när de läses, vad är meningen?
Content strategist Steph Hay visningsgränssnitt som ett tillfälle att samtala med våra användare. Snart blir det bokstavligen.
Intressant har Microsoft gett oss en titt på hur det kan vara att utforma anpassade röstkommandon för våra webbplatser utöver vad operativsystemet stöder med Cortana. Med andra ord lät de oss lära sin assistent.
I Windows 10 kan installerbara webbapplikationer innehålla en Voice Command Definition (VCD) -fil i sidans huvud för att aktivera anpassade kommandon:
Den refererade VCD-filen är helt enkelt en XML-fil som definierar sökordet för webbapplikationen och kommandon som kan utfärdas.
Med hjälp av mycket grundläggande syntax identifierar VCD valfria bitar av en given fras och variabler Cortana ska extrahera:
Grupppost Grupppost lägg till anteckning lägg till en anteckning message med grupppost [snälla] lägg till en anteckning [att] noteSubject lägger till noteSubject till grupppost
Den här appen överför den infångade informationen till JavaScript för behandling. Det har rätt, Cortana har också ett JavaScript-API. Ganska snyggt.
Men traditionella datorer och smarta mobila enheter är inte det enda stället vi börjar se röstbaserade upplevelser. Vi har också disembodied röster som Amazons Echo och Ubi som är helt headless.
Just nu verkar de båda vara helt fokuserade på att hjälpa ditt hus att bli "smartare" -strömmande musik, justera termostaten etc. - men det är inte svårt att föreställa sig att dessa enheter blir kopplade till möjligheten att bläddra och interagera med webben.
I den närmaste framtiden kommer röstbaserade interaktioner med webben att vara helt möjliga. De kommer sannolikt att suga lite först, men de blir bättre.
Jag kommer att göra en lite djärv förutsägelse: medan beröring har varit revolutionerande på många sätt för att förbättra digital åtkomst blir röst ännu viktigare. Röstbaserade gränssnitt skapar nya möjligheter för människor att interagera med och delta i den digitala världen.
Eftersom vi har tänkt på hur de erfarenheter vi skapar är förbrukningsbara över en mängd olika enheter, har vi hoppet på andra som arbetar på webben när det gäller röst. Vi ser erfarenhet som ett kontinuum, börjar med text.
Som röstteknik mognar kommer vi att vara de som människor ser ut som experterna. Vi kommer att bemyndiga nästa generations webbplatser och applikationer att bli röstaktiverade och därigenom kommer vi att förbättra livet för miljarder. Eftersom "tillgänglighet" inte handlar om funktionshinder, handlar det om åtkomst och det handlar om människor.
Visst, vi gör det lättare att titta upp filmtider och köpa biljetter för att se det senaste transformers debacle, men vi kommer också att bemyndiga de nästan 900 miljoner människor världen över-över 60% av vilka är kvinnor - som är analfabeter. Och det är en befolkning som i stor utsträckning har ignorerats på vår dominerande textwebb.
Vi ska skapa nya möjligheter för de fattiga och missgynnade att delta i en värld som har uteslutit dem. Du kanske inte är medveten, men 80% av Fortune 500-företag, tror Target, Walmart-bara accepterar jobbansökningar online eller via datorer. Vi kommer att möjliggöra personer som har begränsad datorkunskap eller som kämpar med att läsa för att söka jobb med dessa företag.
Vi kan hjälpa till att överbrygga den digitala klyftan och läskunnigheten. Vi kan skapa möjligheter för människor att förbättra sina liv och sina familjs liv. Vi har befogenhet att skapa mer kapital i denna värld än de flesta av oss någonsin har drömt.
Det här är en otroligt spännande tid, inte bara för det lyhörda designgemenskapen, inte bara webben, utan för världen! Framtiden kommer och jag kan inte vänta med att se hur fantastisk du gör det!
Responsive Day Out 3: Final Breakpoint hölls i Brighton, Storbritannien den 19 juni 2015.
Denna artikel är en del av webbutvecklingsserien från Microsoft tech evangelister om praktisk JavaScript-lärande, öppen källprojekt och bästa praxis för driftskompatibilitet, inklusive Microsoft Edge-webbläsaren och den nya EdgeHTML-återgivningsmotorn.
Vi uppmuntrar dig att testa över webbläsare och enheter, inklusive Microsoft Edge-standardwebbläsaren för Windows 10-med gratisverktyg på dev.modern.IE:
Fördjupat tekniskt lärande på Microsoft Edge och webbplattformen från våra ingenjörer och evangelister:
Fler gratis plattformsverktyg och resurser för webbplattformen:
