Add new comment

How to Use Drupal 7 to Meet Your Accessibility Goals [September 27, 2012]

Want to learn more about Acquia's products, services, and happenings in the Drupal Community? Visit our site: http://bit.ly/yLaHO5.
Whether you're goals are simply maximizing your profits or meeting your legal requirements, web accessibility is becoming increasingly important. Those who have tried to keep their site accessible while keeping up with the changes in technology will know the challenges that can come with keeping up with the changes in assistive technology let alone best practices.

Fortunately, Drupal 7 is a solid foundation on which to build your website when it is important to you that your site is available to as wide an audience as possible. The Drupal accessibility enhancements which have been made to Core are automatically applied to contributed modules so many of the common accessibility failings addressed whenever you are building a new feature for your site.

In this one-hour webinar, Drupal rock star & core contributor Mike Gifford, will give you an insider view on how to leverage Drupal 7 to improve your site's accessibility.

We'll cover:
• New standards for hidden elements
• Form elements & their adoption by tools like Webform
• Problem areas to look out for when developing for double A compliance
• Best practices to help maintain your accessibility over time

Category: 
Publish on date: 
Thursday, September 27, 2012
Rating: 
Click to see video transcript

Hannah: Hi everyone. Thank you for joining the webinar today. Today’s webinar is “How to Use Drupal 7 to Meet Your Accessibility Goals with Mike Gifford from OpenConcept Consulting. I’m Hannah Corey. I’m a Marketing Specialist at Acquia.

Mike: My name is Mike Gifford as Hannah said and I’m a Drupal 7 and 8 Core Contributor and I’ve also been active in accessibility space having organized some accessibility end conferences or accessibility conference. I’ve also contributed a section to the definitive guide to Drupal 7 for accessibility so that was a nice thing to have the largest and most comprehensive Drupal book to also include the section on accessibility. I’m also the president of OpenConcept Consulting and I’ve been working with Drupal now for over seven years and I’m happy to be part of such vibrant and dynamic community.

I’d like to talk a bit more about, specifically, what are some of the goals that we are looking … What are we talking about when we’re talking about goals and alternative of trying to use Drupal 7 to go up and to accomplish that? It’s important to trying to find what that is. Of course, everyone would like to have a barrier free implementation for the website that is completely universally accessible to everyone that follows the principles of universal design and progressive enhancement and these are definitely worthwhile things to try for.

There is no complex website that is 100% accessible to everyone so there’s an element right now where because of assistive technology and the pace of change in the internet, there’s nothing that's perfectly accessible. There’s a lot that being done to move in that directions, standards and guidelines to help evaluate accessibility, but there’s nothing that’s completely universally accessible. One of the things that...one of the guidelines that’s available is the Web Content Accessibility Guidelines,the WCAG, and this is part of the worldwide web consortium.

W3C is involved in setting up all sorts of standards for the internet and it’s really critical institution for looking at and defining standards for the internet. They released, in December of 2010, they released WCAG 2.0, which is right now seen as the standard that people are looking at for accessibility internationally. There's also a number of draft standards that are being released that are worthwhile to consider and one of them is ATAG, or the Authoring Tool Accessibility Guidelines, and ATAG is still in draft but it’s...anytime you’re dealing with a content managing system, you have to worry not only about how the content is viewed from the user’s perspective but how it’s generated as an author and is it the tool that can, as an authoring tool, also go off and meet the same level of accessibility guidelines.

Finally, section 508, although Section 508 itself is one of the oldest internet standards for accessibility. It was initially published in 1998, and it is in a process of being refreshed and we’re very hopeful that in the next year or two, we’ll see a release of that that is able to keep up with and perhaps, we can exceed the standards set by the international community. Those are some ideas about goals and what is possible within web accessibility, and it’s important that this is something that we do work to establish this as more than just a lip service towards accessibility. That we need to look at what are the practical implementations and what are the practical approaches that we can do to achieve that. A lot of people in their publications and promotions talked about accessibility, but often, that’s more of a sale side than a practical on the ground. This is what has been done and tested and this is what we know worked for people with these disabilities.

I’m not sure what the status is of everyone who is in the call, but I wanted to enhance and talk a bit about the cost of the internet and the internet is constantly evolving, and this isn’t new for anyone here I’m sure, but I’m trying to understand both the clients that the users are using for whether it’s Firefox or Opera, or Safari or Internet Explorer. All of those tools are changing on a regular basis, so are the assistive technology devices that are being used.

If somebody is using a screen reader or is using a plugins tool to enhance the accessibility, these are tools, which change on a regular basis. Likewise, the demands of the internet and demands of what your website are, are constantly going to be changing, and there’s going to be new expectations for client deliverables and what matters as your site is being implemented. Even the software within that is changing on a regular basis as you’re keeping up with Drupal upgrades, and ensuring your site is secure. There may be changes within the code that is accumulated in Drupal, wherein the underlying infrastructure of jQuery or even how Apache is potentially dealing with requests that are changing.

You’re not dealing with the static implementation, and so there’s a need to constantly go through and look for barriers, and look for ways to find ways that your users are being limited too to access on the website. I would encourage people to look for feedback from the users and to elicit information and directions in terms of what's possible, and also to schedule a regular accessibility review. If you’ve done a full audit of your websites, then in six month’s time, it’s important to go up and look at a gate, and look at how, not necessarily doing a full audit, but to look at your website to find the ways to improve the process.

The best practices are changing and there's a lot of dialogue and discussion about what is the best way to approach things, especially when you’re trying to implement something like a responsive design, or you want to be able to even just add any feature like that, a slideer on the front page or something like that, that allows people to have a more interesting visual presentation for your front page. If you’re approaching and upgrading, you’re able to go up routine to look forward and to work with community, then there's always ways to improve and to constantly make your websites better if you’re working with the community of users and developers around the world.

It’s important to plan to go out and see that your website is accessible, and Drupal is a complicated system and accessibility itself is quite complicated. If you’re looking to implement an accessible implementation of Drupal, it’s important to try and leverage what expertise is out there and to where possible eliminate the unknowns. There’s a lot of modules that have some evaluation for accessibility and have some reviews or patches that improve the accessibility of them.

There's certainly places where there are problems that are known and also places where we know we’ve addressed the issue. If you can work with these known elements and read up on the board set that has been done to improve accessibility; that will certainly help a lot. It’s also important to try and contribute back to your changes. You’re going to find things with your users that are going to be ... that maybe something that others in international community have not yet identified. So if you you have an audit done on your website and the person doing it identifies that there's a problem with one particular widget It's useful to go up and to contribute, even those problems back, so that we can work through and try and resolve them as quickly as we can.

I wanted to also talk specifically about this in terms of WCAG. WCAG has a structure of their guidelines called POUR, that all of the information must be perceivable, the website must be operable. It’s important that it also be understandable and finally robust. There’s quite a lot of documentation available on this, but I wanted to make sure that people had a basic exposure to that as well.

Drupal seven has a lot of codified best practices built into it. We’ve done a considerable amount of work in about a three-year period of time to find issues and problems and to fix them in Drupal seven, and also to think beyond a single site implementation to try and say, "What can we do to see that we have a solution that works well for everyone?" I see that a lot of what we’ve done in Drupal seven has a lot of best practices, that if you just follow what is in core, you’re going to have a more accessible website, than not in many cases. When you’re working on developing Drupal that's of course an obvious example of where to look for, for example on how things should be done and how things should work.

One of the great things about core that Drupal Core has built with, there's a lot of information or APIs application processing interfaces, so that you can access the information and be able to organize its potential ways. That’s quite useful as well. The things are centralized and modular so that improvements in Core will propagate out to other pieces to your web setting.

There's also really excellent international communities that meets on a regular basis. There was a sprint earlier in March and there’s another one being organized in November. We do get together and meet, and then look at ways of improving Drupal for accessibility and there's also a very vibrant issue queue as well as the discussion group that we'll provide both of those at the end of the presentations.

Finally, one of the great things that we’ve accomplished in Drupal seven is the ability, not only to publish content that's successful but also to be able to administer the website in a way that is accessible. A blind user can install Drupal, can maintain Drupal, and can add content to Drupal, administer Drupal, and also read the content from Drupal. That operative is seen as a huge issue, but as websites become more interactive, the distinction between what is an administrative piece and what the user piece, they get kind of fuzzy. You may want to have a dashboard available to your users, you may want to be able have a discussion forum where they’re able to log in and have to have access to pieces of Drupal that are, within many cases would only be available for the admin users. It’s really useful to have the flexibility to know that the administrative pieces of the website has also been tested for accessibility and for the most part, had those barriers removed so that people can access the website.

I wanted to talk about some of these specific victories that we’ve brought into Drupal seven and ways that this can help you maintain your website in the future. The first one that you may notice if you’re needing to install Drupal is that there's a Skip to Main function that’s part of all Core themes. This is a great best practice for people who are keyboard only users or people who are blind and use a screen reader to navigate the website. What the Skip to Main section does, is it allows you to jump through all of the navigation that's generally part of a website and get right down to the content. It’s a great way to skip the navigation and get to the content and this is something that's also part of the admin themes as well that come with Core.

One of the issues in Drupal six that became a problem was the drag and drop, and drag and drop is a wonderful functionality that has a lot of – a much nicer user interface for people, but we had to go off and create a work-around so that we could more evenly and intuitively make it so that people who could not use a mouse were able to easily drag and drop the content and have the direct access with content, and to the administration of content rather. There’s also work to go off and improve the semantic markup in the breadcrumbs and the list, things like ... just trying to make sure that especially as we’re dealing with smarter assistive technology, the more semantics you can provide to the market, the better they ... to the assistive technology, the better they can interpret that and provide tools to help the ... or to assist the user in navigating the website.

We’ve also worked on improving the color contrast in the number of places and also added the area support. One of the tools or standards that W3C is building now is the web accessibility area, the Accessible Rich Internet Application Support. It’s nice way to build in more semantics, particularly when you’re dealing with dynamic content, so content that’s changing as you’re clicking on the website. More and more websites are becoming more like desktops than they were, the web pages of even two or three years ago, the type of functionality that users expect, and the type of dynamic responses are so much more complicated than what they were shooting back in 1998.

Being able to present the assistive technology with semantic information that describes what has happened and how to engage and how to go up and to make the information that’s been presented with the user in a way that is meaningful to the assistive technology. It’s a great thing that we’ve started, and there's certainly a lot more than we can and will be adding to Drupal eight, but there’s initial implementations of area for both the auto complete and ultimately, installation pages in Drupal seven. There will be considerably more available in Drupal eight.

Another great tool that we’ve added is a consistent way to go off and to deal with CSS displaying; none or visibility: hidden. This is a well-known problem, and one that we’re starting to have some good solutions for now and certainly the HTML5 boiler place has a solution that’s very similar to what we’ve implemented in Drupal seven. The issue is that assistive technology interprets display: none or visibility: hidden literally, so it will not display the information that's there to a blind user.

You need to actually find a different way to make that information, to hide it off screen and to ensure that people who are ... people do not see the information but it’s available for screen readers. We created a class called element-invisible that allows for screen readers to do this, or that works properly, we've tested it, and this is a larger challenge that one might think, because there are only a few lines of CSS.

Finding a solution that works well and is something that can be implemented across the board is a huge challenge. The solution that we had implemented prior to Snow Leopard, but Apple put out a release of its Operating Systems that destroyed the functionality that we’d implemented before, but simply even creating the class name .element-invisible, and standardizing on that was a huge move for Drupal seven, because it means that even if you want a different approach to how we implement this, you can just override that, but everyone who is ... all the modules and themes have a consistent way to name their information, to hide information off-screen and also to make sure that it’s visible on focus.

That’s like the Skip to Main link that shows up in the themes is one of the pieces that uses the .element-focusable, and there’s other elements where you would want to hide them unless a keyword only user is navigating to that particular element. Finally, there needs to be clear way to go up and hide it to make sure that it’s not presented to anyone, so that's the .element-hidden that’s available there. This will also be supported into Drupal eight, but we are changing the names a little bit. It'll have the same functionality but probably have a slightly different name space.

Another, we’ve done a considerable amount of work is with the Form Elements, and this is a huge challenge for a lot of sites that need to be accessible because so many web forms are not very accessible. The biggest way that they fall down is that there is not a direct link between the description of the input field and the input field itself. There’s no semantic tie between the two. We’ve added a title to ensure that it is with... We have a title setup so that there’s a direct link between the title and the label, so that
anytime you’re creating an input form that that information is setup and structured so that it's consistently convening over to the browser and that there's a semantic tie between the two. We’ve also built in control so that from a programmatic point of view, a developer can associate a label before, after, or make it invisible so that it isn't something that is going to necessarily ... that consistently to hide that information from the screen, but also make sure that it is all hidden from the screen, but it is available for users to be able to ... for an assistive technology to be able to read the information. This is all part of the Forms Application Programming Interface.

Essentially, all modules, and if they have a form associated with it, will use the Forms API to create them, so by addressing things in Core we’re able to go up and to address them in the application. There’s also work that we’ve done in the forms to ensure that there are more headers and greater semantic information associated with the form's interface, so it's easier for people to navigate, or especially for blind users to be able to navigate through the interface.

We didn't fix everything in Drupal seven and we won't fix everything in Drupal eight, as this is a continually evolving process and there is always going to be changes and new standards and new things that need to be addressed. If you're aware with those problems are, then you can look for it and design ... You can focus your efforts and attention on either avoiding them or focusing your programmerss on implementing solutions that will help get around that. In some cases, the problems that have been identified in Issue Queue already have patches for them, and they have a patch that you could apply back from Drupal eight to Drupal seven or that you could go to the modules that will allow you to take the ideas that are discussed in Issue Queue and bring into the application itself.

One of the problems is fieldsets, and complex forms. One of the issues with the complex form is you need to have something to bind them together, and the approach that is recommended is to tie them into a fieldset so that a phone number, if you've got an area code, a phone number and an extension, if those are in three different input forms, that those are bound together and that there's a label associated with the fieldset to explain what it is those different elements are, and that this is part of a group.

Likewise, dates are something that are often not dealt with properly, or if you've got ... if you have even an X and Y coordinate, you want to go up to express. If that X and Y coordinates are in two boxes to graph for accessibility, that should be wrapped in a fieldset. Unfortunately in Drupal, I'm not sure when it came in, but certainly since Drupal five, a lot of the collapsible elements have been done with fieldsets. Fieldsets have been used inappropriately in the past, and we’re hoping to go out to turn fieldsets into details in Drupal eight and address that particular issue. If you’re looking at moving your site to the HTML5, that is worthwhile to look forward to.

There's also some uses of HTML or other implementations like labels were used inappropriately in some cases and now we’re going through it and changing the HTML for that. We’ve addressed most of the issues where labels were used, but there still are some outstanding issues, and you can use the tool like WAVEY. Those will be identified and you’ll be able to see the user interface where label is used inappropriately. When form errors are being ... and they’re much better in Drupal seven than they were, but in terms of meeting AA compliance, and this is something -- this is a goal that the Drupal community has and we haven't been able to evaluate Drupal Core and verify that it does meet the AA standard.

There are some issues there, but we’ve made some dramatic improvements in terms of how error messages are displayed to users. So if somebody's filling out a web form and they hit submit ,a user, a blind user can navigate through that and can see that information, and be able to access the error messages, but they do need to be ... that does need to be improved. In order for it to be AA compliant, you want to ensure that there is a direct link into the issue or if somebody didn’t put in their name, that there's a direct link into or from the error message to the input form to allow them to add that information in.

Also, the publish status is something ... again, if you’re trying to go up, and to ensure that your website is set up for low vision users, there's ways to tweak Drupal seven so that the published status are in fact ... some Drupal themes do a better job than others in terms of marking up the published status, so that it's clearly visible what stuff is unpublished and draft versus what content is published, and the zen theme did quite a good job of that historically, and making sure that that was clearly visible but that’s not a hard thing to build into the theme.

There are also problems with the data tables.
If you’re looking to create data tables there in order to meet the guidelines, one of the things that is being proposed is that -- or one of the things that’s suggested is that there is a scope attribute added that clearly denotes when a header element is ... the header element has the scope of row scope colon. This is particularly important for complex tables.

For Drupal, most of the tables that are generated by Drupal are very simple and there’s very little accessibility advantage for the end user in terms of having this information in here. It's mostly a matter, trying to go up and make sure that the table data meets the guidelines so that it is following the best practices, and there’s a number of discussions on how to do this with both Drupal Core as well as the themes. That’s another area to look at. In terms of comments, if you are unable to comment, one of the challenges is in terms of threading comments, and what is the parent issue versus the child, and sort of establishing that semantic relationship.

We’ve also made some improvements in international innovation that have been brought forward. But for organizations that need to implement a multilingual implementation, you need to have a way to go up and tell the assistive technology what language you're viewing it in. If your main content is English, that’s great. If you have a link to translate to French it should say Francais, so that the screen reader does not trying to go out and pronounce Francais in English. These are useful pieces of things that are going to be added. In fact, some of them have already been added for Drupal six. It’s trying to standardized and build the best practices into Core, and there's certainly a number of issues where we’re looking and working on doing this for Drupal eight that can be used as examples or a great resource for people who are needing to go off and to setup multilingual websites.

One of the challenges that is not just the Drupal, but of websites in general is one of Modal Dialogs. This is essentially switching back and forth between and popping up an interface underneath it. In Drupal seven, the overlays module is a great example. If you’re logging in to the website, and you’ve not disabled overlays, then it’s very difficult for assistive technology to be able to know where the content is and be able to navigate with overlays enabled. One of the things we’ve worked on is a way of ensuring that a screen reader user can disable Modal Dialogs, but if you have people who are content editors who are using the assistive technology, then that will be something that you would want to disable for them because they may not necessarily know that this is a problem with overlays. In terms of the solutions for this, in many ways this is an issue that have been brought forward to the jQuery community, and jQuery is a much larger community of users.

JQuery is used in so many different content measure systems and also for proprietary or custom built web applications because it’s a really powerful JavaScript library. There’s work to go up on, and to be able to fix this you need the latest version of jQuery to bring that into Drupal eight, so that’s something that we can have addressed and have a common way to go up and address, switching the content and switching the focus of users between the pages of you now and to a particular element that they want to be able to access or edit.

I want to talk briefly about best practices now and to talk about things I've mentioned. Having regular reviews for accessibility is quite useful. and I really like the WebAIM’s WAVE Toolbar. You probably can’t see it very well here but there’s a link here for the main Acquia webpage, and I use this as an example of one that all of us will have probably seen having gotten here. If you use the WAVE Toolbar to evaluate a website, you can see areas where accessibility can be improved.

A red mark in many cases will indicate that there maybe there's a missing input form or maybe there's a label missing or maybe there's a heading or something that looks like a heading but isn’t marked up as a heading. It’s a great tool to go off and do a quick evaluation and grab the low hanging fruit. It doesn’t give you everything. None of these tools ... no automated tool will be able to effectively cover all of the accessibility challenges that you need to evaluate in order to make your website AA compliant. It does capture the low-hanging fruit and it’s really important to keep that in mind.

It’s also important to look at training your content owners. Your content owners are -- if they’re not writing good content that's well-structured and it has all text in it, it doesn’t matter how much you’ve spent on building a great framework, if it isn't implemented with the content owners keeping in mind accessibility and using tools like this, or there's another great one called -- a simple tool called CSS Home that basically use just CSS to alert the content owner if there is an accessibility, if there's alt tags missing, if there's use of an attribute tag, there's all kinds of things that can be done and highlighted simply with CSS if the content owners are educated about this, and there’s also growing tools like the Quail Library to do some basic accessibility auditing before a page gets launched.

Again, it requires training for the content office to go up and to have more awareness about accessibility issues. I definitely recommend getting an audit from a professional web accessibility individual, because there are things that you’re not going to be able to see that they are, so if you can look at it ... get somebody to give you feedback on your site from a professional perspective and give you places for improvement, it would be extremely useful. There are not enough websites out there that are actively going out and trying to reach out the users and to get the feedback from the user community, to see if there are any problems or barriers for the users.
I know that we haven’t done enough testing for people who use Dragon Naturally Speaking.
This is an area that if there are people on this call who have done testing or done work with people who have severe mobility issues and need to navigate by voice, the Drupal could probably use a lot of help because we don’t have access to enough people who are working to get access, to navigate the web in this way. Whenever you discover accessibility issues and whatever problems you run into, if you're able to contribute those back to the community, it will help a lot of us to build solutions in the future that address that. This is an ongoing issue, and if we can find the problems and address them in Core or contribute modules, will all be much further ahead.

There’s a lot of continuing work being done in Drupal, and those people who are using Drupal seven, there are 14,000 Drupal modules out there, and you're not using all of them but using a handful of Drupal modules and themes to go up and to build your websites. Many of those may have accessibility problems, and they would inherit things in Core, but they can always be overwritten by the module Maintainer. Almost all elements that we’ve worked to go up and to build into Core can be overwritten, and certainly if people are upgrading websites or modules from Drupal six to Drupal seven, they may not yet have updated their site to the new server or the accessibility standards that have been adopted in Core for Drupal seven. That’s an area that does need attention and you can look in the Issue Queue for any of the modules you use to see what are the accessibility issues that are there.

The ability to tag issues with the tag accessibility, so you can again look for modules that have been tagged with accessibility problems, or in Drupal Core there's also needs accessibility review. There's work done on Drupal eight as well, and in Drupal eight we're bringing the entire interface up to HTML5, and we’re also building Drupal so that it is responsive by design. All of the themes from Core will be responsive and flexible for mobile users. That’s again a huge improvement but it does require testing and evaluation to see how well it’s going to work for users in terms of ... too often people need to go off and added a new mobile theme.

They decided they want to add a mobile version of their website, and forget that it has to also be an accessible version of their mobile site, that in many cases the accessibility guidelines that are available for the main public website, also apply to the mobile website and it’s working with Drupal seven and in the future with Drupal eight, you'll have the confidence that a lot of that has gone through a consistent testing an evaluation to identify and address problems that have come up.

We'll need to have ... When ATAG 2.0 is released, it’s still in draft, and Section 508 are settled, we’re going to need people to review based on that as well, and to look at it and see if there’s ways that we can improve those, and if there’s a way that Drupal needs to be additionally configured in order to meet Section 508. Yes, that will be a challenge when it comes up, but we've made a solid ground work for this implementation so it should be easier for us to go up and to also address those issues. There’s a lot of work that’s being done on accessibility for CQ editor, BU editor and Aloha editor, editor have that fronts with a lot of work on addressing accessibility issues. Those are all part of -- the prominent parts of Drupal seven and eight.

Finally, I wanted to go off and to talk a little bit about the Drupal seven Web Experience Toolkit. This is something that we may be offering as a feature webinar. There's a limited organization that are working together and collaborating mostly governments, but not entirely. The Government of Canada, and University of Ottawa and the City of Ottawa are all collaborating together to go up and build a distribution of Drupal that has a lot of accessibility and usability components built into it. This is something that is going through quite a lot of testing and building on a framework that has been established by the Drupal community, but it’s something that we hope to involve more people who are looking to set up accessible websites, but also people are looking to build multi-lingual websites as well. With that, I'd be happy to go off and entertain questions, and to talk more about ways to get involved in the Drupal community and to address the accessibility issues in the future.

Hannah: Okay, great. Thank you. We have a couple of questions for you. The first is where is the best place to add area landmark in page pcl.php.Javascript or other? Can we attach an area landmark to a region?

Mike: Mostly it depends on whether you wanted to be validated by the ... the reason why people have been adding area in JavaScript is because the W3C validator has had problems with it historically, and I would suggest that the best place to add it is at this stage, in the page.pcl.php file. We weren't able to go up and add it historically into the templates for Drupal because we wanted to make sure that it was something that was going to validate when people went through the W3C. That was why it wasn't added.
There's also elements where the accessible helper module goes and adds them also in a block layer. That’s another space where it’s useful to add area landmarks, is with the blocks that are moving and migrating within the sites. If you can identify those programmatically -- or not programmatically. If you can identify those and expose that information, it helps out considerably. I would say, yes, those are the two places that I would look to add area landmarks.

Hannah: Okay, we have more questions. If I understood correctly the tool will become more linguistically diverse?

Mike: Drupal itself? The Drupal is already quite multilingual, and in Drupal six, the ability to have multilingual sites was brought into Core. It needs to be enhanced, so that you need to have additional modules to make that happen, in terms of a fully functional website, but the Core elements that were brought in Drupal six, they’re also part of Drupal seven. In terms of making it accessible, there’s extra elements that you need to do in order to be able to convey to the user that the language has changed.

To make sure that they have dedicated elements that show up in alternate language ... the most common instance for this is, if you have a website that is primarily in French, and somebody is trying to navigate that website in French, and there’s a string which has not been translated and it shows up in English. The screen reader will try to read that English screen in French, and if there isn't a default means to go up and to convey to the screen reader that the language has changed it won't know how to interpret that text. Did that answer the question?

Hannah: Yes, they didn’t specify anything else. There is one more question that just came in. What themes would you recommend for accessibility especially if you’re getting started with Drupal?

Mike: There’s a couple good themes I would recommend and certainly the Core themes are quite good in this, and has gone through some evaluation. Jeff Burns' is adaptive theme, is the one that we’ve settled on, and that has also brought its way into the web experience toolkit distribution. That’s another great base theme that we recommend. Jeff has been quite involved in the accessibility efforts around Drupal seven. The Zen theme is also a wonderful framework and John Elton has done some terrific work there as well. Particularly, in trying to look at simplifying and streamlining the CSS components, and we are really happy to go up and see the adoption. It’s definitely something that we’re very happy about, happy to see that there’s now a standard, consistent way to be able to programmatically code CSS, which historically is often a bit of a mess.That will have advantages for accessibility, and then also for performance as well. Those are the two main things that I would recommend for accessibility.

Hannah: Okay, great. I think that’s it for questions. Thank you Mike for the great presentation and for answering these questions for everyone. Thank you everyone for attending. Again, the slides and recording on this webinar, will be posted within the next 48 hours and sent to all attendees via email. Thank you.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Filtered HTML

  • Use [acphone_sales], [acphone_sales_text], [acphone_support], [acphone_international], [acphone_devcloud], [acphone_extra1] and [acphone_extra2] as placeholders for Acquia phone numbers. Add class "acquia-phones-link" to wrapper element to make number a link.
  • To post pieces of code, surround them with <code>...</code> tags. For PHP code, you can use <?php ... ?>, which will also colour it based on syntax.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <h4> <h5> <h2> <img>
  • Lines and paragraphs break automatically.
By submitting this form, you accept the Mollom privacy policy.