Accesibilidad: Drupal sin barreras

Extracto de la transcripción automática del vídeo realizada por YouTube.

so this is great to have the last presentation of the day my name is Jesse beach I work at aquia I'm one of the front-end developers they're working on the spark team and for the most part I work on JavaScript CSS and HTML I wouldn't say that i

am at all an accessibility expert but what I am is someone who's very interested in data and access and people getting to information that they need and information that they want so I kind of fell into this accessibility space in October of 2012 at the

Toronto camp the Drupal Toronto camp we were working on the toolbar and we had to meet the accessibility gate the Drupal accessibility gain I had no idea what that meant at the time so I spent a full day working with Everett as you felt Mike Gifford a bunch

of other people and I really got a sense of how far from the mark we were in terms of accessibility and how rich this space is providing means of access to complex applications like the toolbar in Drupal core and it started me down this road of wanting to

make all of Drupal accessible I know I'm not the first person who's wanted to do this I'm certainly not perhaps the best person to do this but I'm someone who jumps into something you know even if I'm stepping on toes and not going over

glasses who wants to see you know good UI be made so this is a talk about what we're doing at the moment in terms of accessibility in Drupal and what we might do into Drupal 9 with perhaps setting up you know an initiative something bigger that gets us

formal structure behind these efforts so if you go to this bit ly URL I set up a Google document with notes I would love it if you know you feel like you have something to say or something to add if you could add your comment to notes on this page I'll

lock down the page afterwards and open it for comments but it'll be a place where we can go back to and find names of people or organizations ideas we can incorporate into later plans so just give everyone like two seconds to jot that down what I'll

do is talk a little bit about what we're doing at the moment and then some efforts beyond okay the reason we want to improve accessibility in Drupal core is because it is simply the right thing to do there is you know you can talk about perhaps economic

reasons you can talk about you know you as a provider wanting to move into a space such as government that requires you to be accessible but from my perspective as a developer there is no justification for building something that someone cannot access in my

mind so if we look at a project like WordPress and I think Mike Gifford for bringing this up during our conversation yesterday if we look at this plug-in and WordPress called WP accessibility has 3049 downloads out of 20 million downloads for WordPress core

and about five million six hundred and eighty-three thousand domains that are running wordpress the reason I bring this up is it was suggested in our conversation then the accessibility support in WordPress is not ideal and if you think about that as a percent

there are 0 point 0 5 36 percent of WordPress sites running this module potentially to improve the basic accessibility of WordPress they're currently 615,000 domains running Drupal and to my mind solving this problem in core means that we hit all of those

domains all of those sites it's not something that we want to push out to contribs phase in terms of support so we are building the standards in Drupal core one of those is the WCAG the web content accessibility guidelines and the a tag are the authoring

tool accessibility guidelines there's a page on drupal.org that specifies that we support these two guidelines in terms of accessibility but we really don't know if we do that's the problem the problem is we we don't measure our support of

these two guidelines in terms of Drupal core and what I'd like us to do as we approach code freeze in Drupal 8 and then the cleanup phase is to think about how we might measure our support of these two guidelines before we produce the official release

of dribbling so what we might do is a full review of all core admin pages every route that we have run it through a validator and HTML validator run it through a tool like the wave tool on Firefox and just get a baseline number of how many errors there are

on that page and then login issue for it we would also want to do a full review of the core templates to make sure that things like field templates have the attributes that are necessary to make those things accessible and then what I'd really like to

see is an effort similar to the html5 effort and the twig conversion effort where we create essentially a scoreboard of every template and every page in Drupal and give it a grade you know or its percent of support if it has three errors in the wave toolbar

then it has you know a negative three score and we want to get them all this year I'm not really sure how we would measure this but we want to have some way of comparing them and knowing when we get to done for Drupal 8 and I would say that the number

of people working accessibility in Drupal core that I see regularly which is definitely not everybody but you know it's maybe it doesn't who are there in the cuse every week I would love to see people who are actually accessibility experts jump in

and help us do testing help us do reviews I don't think you would need too much knowledge of code to jump in load up an admin site run it through a toolbar to check for errors and then log those somewhere on drupal.org so I mentioned a couple of tools

[ ... ]

Nota: se han omitido las otras 2.766 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.