I’m very pleased to announce that the bilingual Pobol Peblig Partnership website has been awarded the RNIB’s (Royal National Institute of the Blind) See It Right standard for web accessibility. For more information on See It Right, other audits and web accessibility visit the RNIB Web Access Centre.
Our experience of the See It Right auditing process was very positive. It challenged our perceived understanding of web accessibility and allowed us to create a fully accessible solution for our client. The following is an overview of our See It Right experience with some examples of issues we faced and how we solved them.
Pobol Peblig Partnership is a Communities First project in Caernarfon North Wales. Communities First is a WAG program to help and support to the most disadvantages areas in the country. Peblig ward lies in the top 10% of the poorest in the country and is eligible for Communities First support. Tai Eryri has been running the project for 7 years.
The main emphasis of the project is capacity building; building skills, experience, knowledge and confidence of the community members, allowing all developments to be community led. The website reflects this dynamic by playing an important role in communication between volunteers, publicity of events, meetings and activities, sharing resources and ideas.
Choosing See It Right
Having previously undergone staff development training with the RNIB. The Pobol Peblig staff decided that the new website would benefit from RNIB’s web auditing process.
As we were in the relatively early stages of building the site, we were advised to go for the See It Right development audit. This audit guides the web development process to ensure that the finished site is accessible. The development audit also allowed us to continue building the site as normal and once the first check was done and the solutions implemented, we were able to apply the same rationale to the continuing build.
The auditor goes through the site checkpoint by checkpoint. When examples of failures are found, they are reported, together with the URL, code snippets and a clear explanation of why they have failed and the impact on users. The report gives a comprehensive set of instructions, telling you exactly what to do to make the site accessible and why.
The emphasis on how the issues impact on the user makes the report more that just a set of corrections. Not only does it explain how to make the current pages accessible but it also provides a framework to enable the designer to evaluate problems in the future, helping with decisions on how to tackle issues from functionality to design and layout.
We had 2 rechecks after the initial assessment. And at the end of the last recheck we had an informal email exchange with our auditor, Bim Egan, giving us the chance to tie up a few loose ends (thanks Bim!). The rechecks allowed us to address unresolved issues from the first report and assessed new issues that had arisen during the build.
Throughout the process Bim was available to answer questions. The answers were comprehensive and relevant to the site’s specific problems. If we had reasons for not wanting to implement suggested solutions these reasons were listened to and we managed to reach a solution which was agreeable to everyone.
Issues with our CMS
When the first report came back we were well on the way with the construction of the site and had started to populate it with content.
We’d chosen to use Joomla as it has a quick learning curve for the web authors. This was an important consideration as the staff at Ty Peblig would be taking over the website updates and management. And from the development point of view, Joomla also has the added advantage of a variety of open source plugins from the Joomla development community. We chose to extend the basic functionality with plugins such as the calendar and comment modules.
The CMS and plugins generate html code snippets for menus, and other content modules and components, which slot into the site templates. By working on the site templates we were able to make the overall structure of the page accessible. Once the changes to the site templates were made we were ready to look at the generated code.
There is a strong relationship between accessibility and web standard compliance. If your site meets web standards you are well on the way to being accessible. Good quality code means your site is easily transported to different user agents and technologies. The various Joomla plugins on offer deliver a wide range of functionality, however there are also wide differences in the quality of code generated. The failed code had to be identified and then modified according to the See It Right report.
Other issues we faced related to the way Joomla dictated how information was organised. We found some code blocks were generated that didn’t make sense semantically when applied to our content. However Joomla was flexible enough to allow us to ‘shoe horn’ our content into the system and generate semantic and accessible pages that we could easily style up.
Layout and Semantic Content
For various physical and technical reasons a number of people use the keyboard tab key to navigate through web pages. The order of the code and the layout of information on the page should be such that the tab order is logical, and focus moves smoothly across the page without jumping back and forward.
In our original design we put a search and contact link on the top right of the page. We’d positioned them here partly to conform to convention and partly in order to visually balance the page elements. Since we had implemented a logical code order in our page, positioning the tools to match our conventional layout moved the tools out of the flow of the document. This caused problems with the tab order.
The expected tab order would be to tab left to right through the section links at the top and then through the tools (search, contact etc) at the top right. BUT we also had a context menu down the left. Logically, the context menu came after the section menu in the code. So after tabbing through the top section menu and down the context menu on the left, the focus jumped back up to the top to get to the tools.
Following the advice given, we repositioned the tools to fit under the contextual menu allowing the tab order to move logically across the page. Moving the tools down also provided extra space across the top of the page so the user could increase section link text size without the text overlapping.
The Pobol Peblig Partnership website is a fully bilingual website complying with Welsh Assembly Guideline: Publically funded projects in Wales must provide all public communications in both English and Welsh. Because the first language of most of the Peblig residents is Welsh this is a very real, practical requirement.
Coding language changes
Language implementation has a particular impact on screen reader users. When the language of a page changes, it must be coded so the screen reader software can select the appropriate language with which to read the page. It is the ‘lang’ attribute that tells the screen reader what language to use.
The language of an entire page is coded in the ‘lang’ attribute of the html element which surrounds the entire page content and meta information. This means if lang=’cy’ every text string that will be read by a human must be in Welsh, and conversely, if lang=’en’, human read text must be in English. If text occurs in this page of a different language to the page overall language, it must be coded.
We used a language switcher, so there is both an English version and a Welsh version of each page. As the site is dynamic and regularly updated we needed to make sure all articles were translated, if no translation was available there would be a line of text explaining a translation was on its way. As it happens the staff have been entering Welsh and English text at the same time so this hasn’t really been a problem.
How to code everyday Welsh
The main problematic issue was the implementation of ‘bilingual’ project titles and organisation names.
The way the Welsh language is developing, as those living in Wales will know, means that words are being incorporated in everyday Welsh (and English) that are hybrids of Welsh and English. Some of the projects use regional slang Welsh for the project names and these names are used whether the residents are speaking Welsh or English.
An example is the walking project ‘Miglo’. Miglo is a ‘cofi’ word which means escape (or ‘dianc’ in Welsh). Miglo is used in both Welsh and English conversations. Another example is the sex education project ‘Jiwsi’ run by the FPA (Family Planning Association). The name ‘Jiwsi’ is a welsh spelling of the English word juicy.
In both these examples the title can be considered bilingual and can be used in both the English and Welsh pages. In other instances, because our residents only used the welsh project names anyway it was harder to establish if these were really bilingual names.
We approached Bim with this problem who returned with this very practical advice: Ask the question ‘would English speakers refer to the project or organisation with its English name?’, if not, use an English translation followed by the Welsh name, if they would, just use the English name.
Training and Accessibility
As our website is a communication tool for Pobol Peblig and they are in the process of taking over the management it was very important that the staff also understand about web accessibility, the impact it has on users and how to make sure new content they put in is accessible.
The clear explanations and solutions given in the audit have allowed us to easily create training material and give practical advice during the handover period. The staff now have a broad understanding of why websites need to be accessible and the types of usability issues that need to be addressed. We have also covered how to make sure the Pobol Peblig website remains accessible. Ongoing website update training will reinforce the specific accessibility issues as they come up.