Presentación
HTML (pincha para descargar)
Vídeo
Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
good morning my name is whim Lyris i'm a senior software engineer in the office of the CTO of archaea and working on spark and i'm jesse beach i'm a front-end developer on the spark team also in aquia and we're here to talk to you today about
how we're trying to make data and interactions accessible to everybody go back one yeah so is that better awesome right so the first thing I have to admit is that I'm not a usability expert and then and reading neither am i what we are are two developers
who are extremely passionate about building usable accessible beautiful delightful interfaces and drupal and i'm sure that everyone out there in this room front-end developers you X developer's community management people docs writers you're also
interested in making accessible interfaces as well but what we're really talking about is building what we like to call rich experiences so this means an experience that is satisfying to someone regardless of the range of abilities yep sorry um so I'm
just going to scroll down so let's talk a bit about whether or not Drupal is accessible already and the answer to this is and the answer to this is yes in a way as a community we have lots of processes and guidelines in place that help us to produce and
accessible products one of these is a pledge that exists and it reads an inclusive community as an inclusive community we are committed to making sure that Drupal is an accessible tool for building websites that can also be accessed by people with disabilities
we also have an accessibility checklist with in Drupal there are 11 items on this checklist some of them include that all non-text content has alternative text that all data tables have headings that users can complete and submit forms and so on these guidelines
are here in order to provide us with a quick means of assessing the uis and the tools that we're building we also have tags for issues that relate them to accessibility for instance the needs accessibility review tag the needs color accessibility review
tag the a11y tag or the alley tag we also have a tag that's just the word accessibility using these tags identifies them as needing further input from people who can test or that they pertain to usability with in Drupal we also have an accessibility pledge
that module developers can assign to their modules to call them out as supporting or in the future perhaps supporting usability so for d7 we had the d7 ax tag and indeed eighth will have the DAX tag we also have a pledge for module developers on this reads
I pledge to make this modular theme as accessible as it can be if you find any flaws please submit an issue link to the issue queue and help me fix them if you can so there are a lot of tools and a lot of means of indicating that something pertains to accessibility
of calling to action folks that can help in this process and it kind of reminds me of a pillow fight in a sense because everyone means well we're all trying to make accessible useable interfaces but when you get down into the nitty-gritty of the details
of doing this it gets messy really quickly you know we're trying not to hurt each other we're trying to be gentle but that still doesn't mean that it's easy to do so this is where we transition into talking about oral user interfaces oral is
a word that means to hear or it pertains to sound and we contrast this with a visual user interface which begs the question does Drupal speak and the answer is you betcha so I really quickly want to let everyone have a listen to what Drupal sounds like when
it's speaking hello this is Drupal welcome to Portland and thank you for attending this session women Jesse are very excited to talk about oral user interfaces and remember put the bird on it awesome so that was just a little string that a screen reader
was reading to us from Drupal we have to question why we should consider speech as an output method for content in Drupal because semantic HTML you know might be enough to express the meaning of the page or the content on the page but I'd like to give
you two examples that illustrate why semantic information is not enough in terms of creating a rich experience so we have here a screenshot of the admin interface this is the config admin interface in Drupal 8 and we see that it's fairly simple we have
links that go to different forms within the content are the config interface account setting site information cron text formats and editors you know the fairly standard configuration main screen now let's take away all the visual styling and we see here
a page that is the stripped-down non-visual semantic HTML for this configuration page and I wonder if anyone would find this acceptable any visual people out there would find this acceptable as an end user experience to sell to a client or to use on a daily
basis and I think most of us would say the answer is no we expect to have our information chunked presented to us well within the confines or the capabilities of the user agent that we're using in fact optimized to the user agent that we're using so
let's have a listen to an example of Drupal speaking to us an interface and we're going to take away the visuals we'll start with the visuals and then as we go and we'll take them away and I should just note here that this is a Drupal 8 interface
we're looking at the tour module I don't want to pick on the tour module in particular this is just the example that that I pulled out there are plenty of aspects of Drupal 8 that have really great support for spoken and cementec interfaces and some
that don't and this just happens to be one that doesn't and if it doesn't play with in a moment we're going to go to iMovie come on internet let's get it a full screen here I maybe just want to pop up project sorry i'm just going to
reopen in there we go and there we go okay let's play this one what you want then you will be no front page open for an cop a job in Firenze window front page open paren content closed for Angela ld8 dev tab exited dialogue skip to main content internal
at home page navigation admin menu shortcuts tour button not pressed enter dialogue exited navigation next internal link entered dialogue next internal link enter dialogue next internal link pex internal link next internal link enter dialogue next in entered
dialogue next enter dialogue next enter dialogue next enter dialogue next internal link enter dialogue next intern entered dialogue and tore internal link we know front page open paren content you know and to talk about usability and accessibility even I movie
is fighting me the entire way all right great so I was watching over ones faces as they were listening to that and I saw people kind of sort out skeptically and then as we got to the fifth or sixth dialogue people started to wonder where in the world we were
in that interaction and that was exactly the reaction we were going for it's very easy to get lost in an interface when you don't have the visual input and then to not even know why you're there after a while and to know when you've finished
if we look at the the mark-up for the tooltip that was part of the tour module we see that we have taken steps to make this accessible right it's not just dibs on a page we have a div with a role of dialogue we have Aria semantic attributes we see P tags
and h2 tags there's an attempt to make this semantically accessible but when we take that semantic you know underlying element and put it into an interaction suddenly moving between those elements doesn't have any meaning so as we've been thinking
about this problem women I have attempted to visualize what or how Drupal does in terms of its visual versus oral interfaces and to plot them on a scale so we've plotted them on a scale from inaccessible to delightful interaction and if we imagine that
inaccessible gets a value of zero and delightful interaction gets a value of one ce4 because we're engineers I'm account from zero we can plot the visual content consumption experience see visual administration experience the oral content consumption
experience and the oral administration experience and we see that in our opinion both of the visual experiences content and administration both fall within you know barely usable to you know almost delightful with the constant consumption being the one that
has the higher upper bound if we compare that to the existing aural experience we see that the upper bounds make it just to acceptable interaction and the lower bounds range from you know barely accessible in terms of the content consumption to inaccessible
in terms of the oral administration and what we're trying to do in our work in Drupal 8 is to raise the lower bounds of these experiences to at least you know barely accessible as a minimum and we would like to get all of these two barely usable because
when we get to barely usable that's when we can start talking about usability and improving these interactions towards that level of delightful not just you know making them accessible we really want to hammer home this idea this is something we've
internalized that accessibility is not just a word that means non visual what we're talking about is making interactions and data accessible to everybody all right and what complicates this is that the dynamic applications that we're building into
Drupal 8 undergo state and property changes so it's not enough just to mark up information semantically we also have to describe the transition from the states that they begin into the states that they end up in as we move through a dynamic application
[ ... ]
Nota: se han omitido las otras 4.854 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.