- [Man] Feel free!
(audience applause)
- Thank you.
Hi, everyone.
We're here to tell you about
well, how to design an
award-winning website.
There is a disclaimer, of course.
There is no guarantee
that this will actually win you an award.
Also, I have a small trigger
warning before I start,
because we'll be using some words
that may offend some people.
(audience laughing)
There's a couple, so we'll
warn you about those.
So, how did we win an award?
And what is this all about,
what is this award about?
Last year, December 3rd,
there was an awards ceremony
in Nashville, Tennessee at WordCamp U.S.
These were the Automattic Design Awards,
they were organized by Automattic,
the company behind WordPress.com,
initiated by John Madea,
and they wanted to celebrate
good design in WordPress,
in WordPress community,
or built on WordPress.
Now, let me do a quick
introduction because you may
wanna know who I am and who we are.
I'm Peter, I run a company
called Frozen Rockets,
it's a design studio.
Last year, KIT Royal Tropical Institute,
they called me and they asked me
to help them design a new website.
KIT is a knowledge institute,
it's focused on sustainable development,
and I knew it was going
to be a WordPress website.
So, naturally I wanted the
best developer for the job,
I called Luke.
- Hello, I'm Luke, I work
with WordPress (laughs)
(audience laughs)
I'm also a freelance
developer and designer
and I work with lots of systems.
- And there were a couple
of other people involved
on the client side,
also on the design side.
This, for the non-Dutch people here,
this is called a distributor team here,
we're about an hour away from each other,
so it's kinda cute.
So this award, they had two main criteria,
it needed to be Gutenberg Ready,
it needed to be ready
for the future basically
because Gutenberg is a new
content editor in WordPress,
and they wanted to have
accessibility enabled.
They wanted to honor work
that shows that strong
accessibility and strong
design go hand in hand.
And this is right up my alley,
because this is what I'm
trying to do in my daily work.
I'd much rather win an award like this,
than some flash of the
year website, I don't know.
So, what did we do?
I think for a strong design,
which they wanted to have in this award,
for that to happen it's important
that you create the right
conditions, you set the stage,
and not every project will
lead to winning an award of course,
and neither should you aim to do that.
But there are a lot of parts
that you do have control of
and it will make it work better, I think,
and much more easy and
much more fun probably.
Meetings, for instance,
meetings are often this thing
that, it kinda just happens,
and everyone is there
and we're wasting time and
no one is really having fun
and it's not really productive.
So you can be much more intentional
about the meetings that you have.
There's a great book
that came out last year,
called "Meeting Design" by Kevin Hoffman.
"Gamestorming" by Sunni
Brown is a great book.
In our kickoff meeting,
we did an activity,
it's called a pre-mortem.
In projects that went wrong,
it's common to do a post-mortem,
where you kind of ask yourself,
after the fact, "What went wrong?
How did this project went off the rails?"
But that's after the fact,
you're retroactively
finding out what went wrong.
A pre-mortem is a way that
you look ahead at a project,
its a pretty straight forward activity.
You start the project
by gathering your team
and you're trying to come up with reasons,
any reason basically, why
this project might go wrong.
Any sort of, well, just be creative.
You're trying to imagine
yourself, a month, or six months,
or however long your
project is going to last
into the future and sort
of come up with reasons.
Because by doing this at
the start of your project,
you can set yourself up, well,
at least you can set up a plan to
mitigate the risk.
So that's what we did, we
had a couple of challenges.
Wanna go back? (laughs)
(audience laughs)
We had a couple of challenges.
One thing is that
we had a pretty tight
deadline to work towards.
It was about four months
for the whole project,
from start to finish
and that included a
full content migration,
so that was a big undertaking,
Another big challenge we
recognized pretty early on
is that we needed to balance the interests
of KIT'S different departments.
On the old website,
each department basically
had it's own website.
It was a WordPress Multisite
and they all had their
own buckets of content,
their own interests of course,
and the new website needed to be migrated
into one cohesive whole
and we still needed to
keep these stake holders happy, of course.
Now, I like to call design
projects sort of self help
for organizations because that's
where these power struggles
and friction sort of comes
through the surface and
well, you need to take that into account,
if your designing or
developing anything because,
well at least, we wanted to do that.
We wanted to design, with
accessibility in mind,
in a user-centered way,
so you need to know how
to package that in a way
that they think it's their idea,
that's a great idea that we're doing that.
So we started the project
by gathering as much data as we could
because we needed the
ammunition to convince them.
So we gathered information
about the old website.
We did some top-task
analysis, we gathered data
about the organization,
about the stakeholders,
about the politics, and
of course about the users.
So, KIT's redesign,
it was part of a larger
rebranding program,
it aimed to promote cross pollination,
collaboration across departments,
so we knew we had to come up with a design
that put this whole
concept front and center,
we needed to look for
overlap and see where,
well, how they are
different these departments,
but also how they are similar.
And with some exceptions
they are all pretty similar,
of course they're all
unique, at least, well.
But, they all do applied
scientific research
and it's all kind of based
around sustainable development.
So that meant that everything
that happened within KIT
was in some form related to a project.
So, they offer different
services as part of a project
which are then executed by their experts,
ideally experts from
different departments.
An alternate publication,
like a scientific paper
can be outcome of this project.
So, with this in mind,
this project, as sort of
the cornerstone content,
we had something to work with,
because that was a place
where we can link to gather these things
into a way that makes sense.
And this was consistent with
some of the top-task research
that we did on the website.
We ran this little
widget on the old website
where we gathered as much
data as possible about
people who visited the website,
who were interested in doing something.
So we basically asked them,
"What are you trying
to do on this website?"
And well, "Did you achieve
your goal? Why? Why not?"
All these kinds of input were
all used in the newer design.
So, we started by
designing the project page
as the first template,
and as Stephen mentioned
already in the talk before,
I also do a lot of writing,
I just write stuff down as squiggly lines,
there's boxes, there's arrows,
because we wanna see connections,
we wanna see patterns, and
at some point during writing
these patterns start to emerge,
we start to see sort
of, "This makes sense,
this could be a page."
And of course we looked
at other data as well
to see where there's room for improvement.
Now, I know you're mostly developers,
so I'm sorry about the C-word,
there's another trigger warning here.
We're designing an interface
that allows visitors
to interact with content,
this is what a website is mostly.
So everything we do should be about
opening up that content to those visitors,
and that is why content should be
on your mind throughout the project,
because that is also what, for
us, accessibility is about.
We wanna make sure that
visitors can see the content,
can access the content of the website.
So everything we do is about that content
and we're trying to open it up
to as many people as possible.
So after sort of
sketching discovery phase,
that's the point where I like to jump into
a wirefaming kind of,
this is text based design,
this is basically just writing down,
markdown, for content of the page.
It is also my first steps
towards actual wireframes,
toward actual prototypes,
this is very much influenced by Stephen
and the book he mentioned
that he wrote a couple of years ago,
it's called "Responsive
Design Workflow" of course.
And I use markDown for this,
because markdown allows me
to quickly transform this into
different formats like HTML.
And HTML is a great starting
point for a prototype.
Now, there's not much CSS going on here,
just some for alignment and
maybe some visual hierarchy,
but that's basically it.
But you get a feeling
for what the website is
starting to look like already,
at least in terms of
information architecture,
hierarchy, navigation.
Also notice that there
is no lower mid smear,
we wanted to use as much
real content as possible,
because we wanted to know
what this website would actually be doing.
And that's also what this
website is about, right?
It's about content and it's
about structuring content.
On the visual design side,
we were lucky to work with
Stephan, he is a great graphic designer.
He was working in Parallel,
did explorations on visual direction
but it didn't influence
the interaction design
or at least not, it didn't
direct interaction design.
And also not the other way around because,
as Stephen mentioned,
you don't want to reduce
your visual design
into a sort of paint by numbers exercise.
So we took this project page
as a starting point for our design
and we built the rest around it.
So we have this, sort of,
mobile website kind of view.
It's just one text column
and the rest is moved
out of the way to decide,
it's there but it's not as,
what's discretely buried in the sidebars.
And we did that for relative content
because we wanted to
use this project page as
a page that could link together
different pieces of content
so, serves as experts and
other related piece of content.
Now we presented this, and I
think it's important to note
that if your presenting
your design to your clients,
that you should use that
data that you gather,
that you should take control of the room
and that you shouldn't make
it about taste, colors,
typography, whatever.
They don't really care about that I think,
it should serve their business,
so that's what we were trying to do.
I think it went well
because, we got sign-off,
and I was still on my way
to make this project
secretly about accessibility,
and this is when Luke takes over.
- Okay, so,
we now have our wireframes,
we have the beginning of
a visual design basically,
and this is
the first time in the process
that I actually get to do some work,
I get to do some coding.
I mean, I was at all the meetings,
I was at the pre-mortem
and we talked a lot about,
maybe, the intricacies of the
technical spec we were using,
but in this case we finally get
to some backend development.
Again, that's a trigger warning,
and heads up there's another one coming
because we're going to talk
about the mammoth in the room,
which is WordPress.
WordPress is gigantic, it's
ancient and it's kinda hairy,
so for developers, I can definitely see,
why the stack overflow
developer survey of 2019
ranks WordPress as the most
dreaded platform ever. (laughs)
It's been in the top five for a few years
and we finally reached
number one. We did it.
But it's, it's
really not that difficult
to see why it's now the
number one dreaded platform
and that's because WordPress
is over 16 years old already.
In web terms, that's ancient. Right?
And I promise you that if you'll go
and dig through WordPress Core,
you'll come upon code that
was written 16 years ago.
Some of it, even not namespace correctly,
or prefixed correctly.
All of these years of adding
API's and new technology
to that platform have lead to
gigantic technical debt for WordPress.
Fun fact, if you take WordPress Core
and put it though Code Climate,
which checks technical debt,
then Code Climate will tell you,
that it will take one developer
working reasonable hours,
approximately 15 years
to get rid of all the
technical debt in WordPress.
Whether or not that number is exaggerated,
I don't know.
It's a clear sign though that,
yes this is an ancient platform.
But WordPress now also powers
approximately 34% of the web,
which is huge right?
I mean, there's clearly
some kind of disconnect here
between developers and what
they would like to work with
and users.
I mean, it's being used
by giant publishing
houses like Time and CNN,
whether or not you think
this is a great example,
but The White House currently
also runs WordPress.
So, this mammoth isn't going anywhere.
And lucky for us, it isn't stuck
in some sort of permafrost,
there's constantly new Lapis coming out,
and I promise you it's quite
possible to work with WordPress
and still keep your sanity.
I mean, I'm still standing.
And another trigger warning,
ready for the accessibility
people in the room,
because we're going to talk
about WordPress's latest tool,
which is Gutenberg and the
accessibility people in the room
will already know why this is troublesome.
I'll explain to the rest later.
Gutenberg was created to
replace the ancient tiny NCA
content editor in WordPress.
It's a block editor,
it's completely modular,
it's written in React
and modern JavaScript
and at a time that we were technically
Spec-ing out this project
Gutenberg was already kind of stable.
I mean, the block API,
which we needed to create custom blocks
was very stable and then the rest
was kind of a moving target still.
But, overall, we made like
a pro and con list saying,
"Should we use the new shiny thing?"
And there were a few pros like,
"Okay if we do this,
we're future oriented,"
Gutenberg was scheduled for
a release in August of 2018,
we were scheduling our
release on September of 2018,
so, releasing a website
that then immediately is
outdated seemed horrible to me,
another pro is, it's fully modular,
and the biggest one,
and I think that's the most important one,
is we had a content team that
was very well aware of the
capabilities of modern web applications
and how content could and should look.
So, giving them access to an
easier to use content editor,
that's maybe not completely
ready for live environments yet,
but still, we might be able
to work around with that.
That was for us, the main
reason to go with Gutenberg,
like, the shiny new thing in your project
that's all well and good
but if you do not have
an excuse that incorporates
either your clients best wishes
or your users best wishes,
you might think again on
using that shiny new thing.
So we have these wireframes basically
and this is the project page,
we knew we were going to
create the project page first,
because there were many projects
and this was the cornerstone content,
the content team needed
to basically gather
all of the projects From
seven different websites
and turn it into a single
page, a single site.
And we already know
that we're going to have
to build some blocks here.
Custom that aren't in WordPress defaults,
but the benefit of module
learning or modular developments
means that we can first look
at where there's overlap.
We can start looking at, well,
what are some things
that we're going to need
throughout the sites that are
without even looking at blocks
that we're going to reuse.
And then we came to
the related content section of projects.
So ,I was actually
involved pretty early on,
even without the design phase being done,
and seeing if we could
create related content.
Now, there's basically two ways
you can do related content.
You can fully automate it using tags
and categories and such,
or you can hand pick 'em,
which is just a link.
But I went to the KIT content team,
because at this point my target audience,
the people I was developing
for were the KIT content team
and I asked them, how much
editorial control do you want.
I mean, it's kind of
strange to develop something
and then later go to your client,
ask for permission to use it
and if you are lucky they'll
let you get away with it
and if you're not lucky,
they'll give you a giant list
of changes you need to make.
So, "How much editorial
control do you need?"
And we ended up using a
sort of hybrid solution
where we can just, we add an
expert block in this case,
we type in a name, we
can type in a profession.
But there's also that
little button underneath it
to search for an expert,
or we can just search through all of the
experts in WordPress itself
and then it'll automatically populate it.
And then once that's
automatically populated,
this link is live.
So if you change something
on the site of that experts,
it'll get changed in the block,
unless you override it by hand,
like changing the email
address, for instance,
then it will always show
that single email address
on that single page.
So, this is just a simple React
component and in this case,
we definitely did use a
button tag, don't worry.
But, we can drop this in anywhere
and we ended up using this
in seven different blocks, I think.
Of course, I was enthusiastic about it,
so I wrote something
on twitter and then,
party pooper Peter said, "How
about keyboard accessibility?"
I said, "Well shit, yeah, you're right,
it's not keyboard accessible yet."
So, I took half an hour and
made it keyboard accessible
even though my current target audience,
the content team at KIT, at that moment,
there was body there with a disability,
everyone was using a mouse,
there was no problem but,
we had no idea what that
content team might look like
in a year or in five years.
We had no idea if we want
to reuse those components,
the entire idea of modular design
and modular development
is that we can reuse
some of these building bricks later on.
So, we ended up building
six custom components
and then using 30 custom
blocks basically for KIT.
And we had the luck that we could
immediately test everything
with our target audience.
So, we just had a select
channel set up basically,
and I would show little
sketches of fields and UI's and,
"Would this work for you?
Would this work for you?"
They would give very quick feedback
and eventually, things got into code.
You have to be lucky
with a client like that,
that also respects your boundaries,
but is also willing to provide
basically constant feed back.
But, if you have them,
please make use of them
and just set up a select
channel like this,
it'll help you so much in the long run.
Communication between you and a client
is very important in that way.
Now, we've basically created the backend,
the content team's already
churning out new project pages,
and I'll leave it to Peter
to talk a bit about the
front-end development.
- Yes, now this should
get everyone excited
because we're at Frontend
United of course,
and we all want to talk
about front-end development.
And not so much about how to
do design presentation, maybe.
So, I'm gonna make ya happy,
I'm gonna show you HTML.
This is HTML that gets outputted
by some of the blocks in Gutenberg.
So this was was a related
expert for a project
and now we can start styling those,
because we had the HTML, we've
thought about the content,
and the structure of that.
And now, we kinda knew where
we were wanting to go visually.
So we had some basic
skills that's in place
and this is where we can
start to work on the design
Of course we did some visual design,
we did interaction design,
but we also did a lot of
design in the browser.
And when people talk about
designing in a browser,
they often assume that all design tools,
static design tools are
thrown out the window.
No one uses Photoshop
or Sketch or Fakemile,
whichever tool you prefer these days,
are thrown out the window
and everybody just becomes
a front-end developer
or a UX engineer or whatever
it's called these days.
They start typing code and
everyone's a designer now.
But I much more prefer Denmo's idea
of not designing in a browser,
but deciding in a browser,
because there's value to
these static design tools
for figuring out stuff,
but there's also value
to working in a browser
to decide on responsive behavior,
on the foremens, and
accessibility of course.
These are things that happen in a browser,
so you need to treat it as
a website, because it is
work with the material.
So when we take this HTML that
Gutenberg sent to the browser
and we add some more styling,
now we have a website,
it's starting to look like something
and we can start working on
the specific details, like
like, there's no hover styles
and when I've got through it,
I only see the browser
default focus styles,
which is of course better then nothing,
but we can improve on that, I think.
I knew I had your attention
when I mentioned front-end development
but, well, plot twist, this is
actually about accessibility.
Because I wanted to talk about
how thinking about accessibility
and keeping that in mind
throughout the project informed
some design decisions that we made.
Let's look at keyboard
accessibility for instance.
I mentioned focus styles,
so, not much there, no hover styles.
Of course, we can add
a underline for hover,
nothing fancy, this is
one where you wanna stick
to conventions probably.
And we add a focus style,
and instead of removing the outline,
let's make it a bit more explicit,
because we want those
keyboard users to also,
well, like this website.
Also, see how long this took
me to design that focus style,
there is no excuse for not doing this.
And we did this throughout the website,
we wanted to make sure that keyboard users
would find this an easy to use
and pleasant to use website.
Now, let's take these
card components to sort of
well, this is a very familiar
thing, this card grid.
Sorry, some basic HTML,
there's early styling,
class of card, and then
there's a link inside
and an image.
Don't forget the alt-attributes,
never, of course.
And we had some basic
styling for hover and focus,
for the links, just the basic underline.
But, although this
technically covers WCAG,
accessibility guidelines, we're compliant,
we're accessible.
Accessibility is also about usability,
so how can we improve this,
we can improve this by adding
a focus within, for instance.
It's a relatively new CSS
property, but it's well supported
so, if an element in
this card, in this case.
So the link has focus, then
do something to the card,
in this case add a box-shadow for pixels.
What this does is now, it
makes it a bit more clear
where you are on the page
and makes it easier to
navigate, with a keyboard.
We also added things like, of course,
skip links, because
they deserve attention,
it's nothing special, nothing fancy,
but it's often left out or forgotten,
because now a keyboard user
can skip out the
navigation items search box
and they can jump right into
the content if they want to.
So this is a free accessibility
testing that I give you.
Everyone can do this, there's
no excuse to not do this,
just throw your mouse out for an hour
and just start using your keyboard.
Do this on your websites
and you'll start to see
these patterns appear.
Things that don't work, models,
other kinds of pop up
things, custom form elements.
This is really easy, this is
free, everyone can do this.
So, like I said, the nice
thing about working in code
is also that we animate things.
So this one slipped through
the cracks in the design phase.
The color for the word project
had a too low contrast on the white.
That can happen, but
since we have this in code
and we're designing in code
and not all design
decisions have been made
in a sort of silo design phase,
we can still make these adjustments.
And this was a result of the brand colors
that we were working with.
We've already figured
that some combinations
would probably not work, yellow on white,
probably not, black on blue, probably not.
We had enough experience to
recognize these, but some were,
well, we didn't see them right away.
So, what we needed to do is
come up with more options.
But this is not something that
we did in the design phase.
This is something that
happened in the browser,
this is something that we did
during front-end development,
or what you would traditionally
call front-end development.
In this case, there was a lot
more options to work with.
Nothing special, just chose a
slightly darker shade of green
it was still on brand,
but it made it much more easy
to read for many more people.
And this is also a benefit to working
with overleaping
disciplines, this is where,
these are things that you
want your designer to do.
These are not things that,
you don't want a designer to hand
a list of color
combinations or color codes,
shoot them in Gera
or whatever back tracking
systems you have.
So a developer could spend
a portion of his day,
to change color combination code.
There are much harder
development challenges to solve probably.
And, well, we spent quite some time
making sure the content
is visually structured,
and there's a clear visual hierarchy,
and we also wanted this to be reflected
in the non visual structure of the page.
So, heading levels,
when you use some word processors like
Microsoft Word or Pages, or Google Docs,
you can have this auto generated index.
If you use the right heading styles,
you can just generate an index (murmurs)
and it'll make it for you.
This is what (mumbles) users can also do,
they can call for all
the headings on a page
and it'll create a nice index of a page
and they get a nice overview
of what this page is about
and they can navigate it that way.
These are all, not hard
things that I mentioned.
I mean, keyboard accessibility,
card accessibility,
using semantic HTML, it's not hard.
Accessibility problems,
some people might have
a different opinion.
But, remember when I said
this was about accessibility,
well, it was about front-end
development all along,
because this is part of our job,
these are not things
that an accessibility
expert should be fixing,
these are things that
come with responsibility
that we have as developers
and as designers
and it's all these tiny things
that add up to a more accessible website.
The website we made is not perfect,
but it's doing pretty well,
in terms of accessibility
and it makes it usable
for much more people
And this is on you, there's no
excuse for a project manager
or Scope or whatever,
because no project manager
will as you to use a div for
a span instead of a button.
This is something that you do,
this doesn't take extra time even.
So, we have, sort of, front-end templates,
and as much as I hate silo working,
it still needs to work in WordPress,
it still needs to be
implemented in Gutenberg.
So, there was one silo and there was Luke,
so I'm gonna hand this over to you
because I'd like to
leave this to the expert.
- Thank you (laughs).
Yeah, so we now have front-end designs
for all of these nice components
and we have a decent back-end
to those contents being added.
So, we're on the right track.
But then, the last stage
basically of this entire process
is me making sure it all fits together.
As I mentioned, Gutenberg
is a content editor,
meaning you can create a perfectly
good medium post with it.
But, it's kinda hard to use
it for things like headers,
footers, navigation menus.
It's intention is to finally shift over
from a content editor to that,
but we're just not there yet.
And we would think, well,
"Are we going to introduce
this content team
to another interface?
Are we going to, how are
we going to solve this?"
and we basically said, "No,
we want to work with blocks everywhere,"
we have this cool system set up now,
so everyone can basically create blocks
and we have infinite expandability.
So, how are we going to do that?
A couple of months ago
I had this talk on my desktop entitled
"Ugh! WordPress," and it
made me think of this,
when I first saw how Gutenberg
in WordPress saves data.
Because this is what it looks like.
All the information is in an HTML comment,
and then there's HTML in between.
If you look at the entire page,
this is what it looks like,
just one giant blob of HTML,
there's no structure here.
This is basically just being presented as
"Here, puke this in your main
elements and be done with it."
So, we need to do something to make sure
we can run Gutenberg
in an accessible manner
so we can actually differentiate
between the actual content
on the page, related content,
side bar content,
metadata, stuff like that.
So, how do we go about
producing a full page of semantic HTML?
Well, this is one of the big
loose ends of Gutenberg itself.
Gutenberg, by the way,
you can run completely
apart from WordPress now,
it's a stand alone thing,
it's running in Drupal,
it's running in Laravel,
it's probably running in a lot more CMS's
and systems than I know about.
But the thing is, this way of saving data,
that's unique to WordPress,
so we gave it our own WordPress flair.
But there's a way in Gutenberg
to basically just get
an entire neat JSON file
of all the blocks on your page back.
So we basically had to
get around WordPress Core,
and say, when you save a post,
don't save it the regular
way, that's stupid,
just save it like loose
blocks in the data base.
And now that we have this exploded blob,
we can then start putting
it back together again,
and in a semantic way.
I mean, we can have in the article
and that article can have a footer
and it can have an aside
for related content,
stuff like that.
Now, why did we do it this way?
Well, the main reason,
again, is accessibility.
We wanted people to use this site,
wherever and whenever and
that includes semantic Markup.
You might say, "That
seems like a lot of work,
why didn't you just do
what WordPress suggested,
puke it all into a main element
and then use CSS To
basically fix the layout?
Well, I look at these
two images, and I think,
where would I rather work?
What would I rather come back to?
Doing semantic HTML and doing quality code
isn't just for accessibility,
or for code review or whatever,
it's about first making
something that you're proud of,
and then second of all,
making something that's
easy to come back to later.
'Cause let's talk about what a user is.
I mean, yeah,
users are people that
are coming to your sites,
but users are also authors,
writing content on those sites,
they are editors or admins,
that are making sure
the site runs smoothly.
Users are even other developers
that have to work with your code later on.
I don't know if any of you know that meme,
the amount of fucks you hear,
means the quality of the
code is going down, right?
That's one metric we're trying to avoid.
And other developers in this case,
can also meme you in the future again.
So, just leave it as it
should be. Do good work.
Now, all of the changes Peter talked about
and the things I talked about,
these aren't big things,
they're small incremental changes
that eventually add up to an easy to use
and accessible website.
Accessibility happens in the in-betweens,
it happens inside the design,
it happens inside of
the development phase.
It doesn't happen on it's own in a silo.
Same for user experience.
This might be a way of
how people still work
but I can guarantee you.
Show me a manager that had
a project come up in time,
and in budget and on Scope,
and I'll show you what's wrong with it.
Now there's one thing I'd like
to talk about at the moment,
which is I'm very proud
of the work we did on that website
and I'm very proud of
the code we left behind.
But the thing is,
Gutenberg itself currently
isn't accessible yet
by a long shot in WordPress back-end.
It recently had an accessibility audit,
which was released last week I think.
And they said Gutenberg
can be described at best
as poor to okay.
The accessibility audit
lead to 90 new issues,
of which 70 were critical.
Simply put, we need some help.
I have no idea if there are
any React developers in the room,
but your bound to at least
run in to them during lunch.
If you know React or if
you know modern JavaScript,
you have a base understanding
of accessibility.
Go to, Gutenberg's get
up page, download a copy,
install the stand alone version,
I'm not asking you to install WordPress,
and try to fix tickets,
because this stuff is real.
I mean, this is running
on one-third of the web.
More even, if Drupal is bringing in users,
Laravel's bringing in users
and it's a stand alone thing,
So. that's my call to action to you,
but, we made a talk,
telling you how to design
an award winning site,
now the thing is I don't think
I have an answer for you.
The only thing is, we
have this jury quote,
when we received the award in Nashville,
that said, "Having inclusive
design incorporated
into every step of the process."
and I think that's what
I'm most proud about
in this project.
And why I like that we
actually won an award for it.
So it's always possible to
make sure you incorporate
good accessible user experienced
design into your projects,
if accessibility and
usability wasn't in the budget
or the Scope there's something
wrong with the budget
or the scope, and your allowed
to say this during meetings,
you're allowed to make some noise
and bang your fists on the table.
Small stuff and attention
to detail from you,
eventually will add up,
and there's no excuses
not to make a great site
or a great project, thank you.
(audience applause)
