By Private Profile 73e10be2 on 2018-05-14 08:40 in Joomla Accessibility Team

Date: 9th-14th May 2018
Location: Cologne
Participant: Marco Dings (guest for parts meeting),  George Wilson (guest for parts meeting),  Armen Mnatsian, Ray Selby, Christiane Mayer-Stadtherr, Stefan Wajda, Andrzej Kasprzyk, Justyna Michallek (one day, joint by Skype).
Time: 9th May 09:00 UTC - 17:45 UTC
10th May 10:00 UTC - 20:00 UTC
11th-13 May - a total of 6 hours

We organized 5 working sessions of the team. We started on 9th May with Marco Dings, Armen Mnatsian and Ray Selby. On May 10 we worked all day with Marco Dings (part day), George Wilson (part day), Ray Selby, Armen Mnatsian, Stefan Wajda, Andrzej Kasprzyk, Christiane Maier-Stadtherr, Justyna Michallek. During the JAB (11-13th May), we conducted a total of 6 hours of working sessions.

In addition, we met all of the following JAT members who participated in the JAB: Carlos Camara, Sigrid Gramlinger, Dimitris Grammatiko, Christiane Mayer-Stadtherr, Armen Mnatsian, Rick Spaan, Noemi Sanchez del Rio, Stefan Wajda.

Introduction

We started the discussion with Marco Dings, Armen Mnatsian and Ray Selby. The idea was to find a a way to organize the JAT project structure in a way that makes it clear and understandable, which, in turn will generate clarity and motivation.

Marco pointed out that SMART (https://en.wikipedia.org/wiki/SMART_criteria) is probably the best  way to deal with this. He suggested that we create an Excel sheet that we can dynamically work upon. This will be created, in the form of a nested tree structure.

At the top of the tree (left side of the sheet) we put the goal of the project and, in subsequent columns, we break down the tasks into ever more specific categories of tasks. The goal is to have work packages and building blocks that are arranged/categorised according to the MoSCoW method (https://en.wikipedia.org/wiki/MoSCoW_method). The packages are intended to be SMART, so they can be handed to “any” developer for implementation.

We began with the first layer, Installer, Backend, Frontend and New Media Manager and also began with further breaking down the Installer into task categories - Generic structure layout, Installer Language choice, Site name, Login data, Database configuration, Site language choice and Sample data.

All we are doing, here, is finding a way to structure our path, not to create any final or completed result. On the contrary, we assume that it will be dynamic document, modified as necessary - the focus being on functional decomposition, from an accessibility perspective that is agnostic of the implementation used. We focussed on the functional decomposition of Joomla, from an accessibility perspective, to the elements that can be a starting point for the preparation of work packages.

We use terminology that is different from ones used in the implementation, which is why we are using the term “presentation elements”, instead of “custom elements” that are specific to html, where “presentation elements” does not have that limitation.

Each of the above task categories has a number of considerations, for accessibility - e.g. presentation elements. Each documented presentation element that is used, in the part under consideration, is added in the following column, as further sub-categorization. This will mean considerable duplication but that is essential, so that the one allocated to the work-package can see if the same work has been previously carried out, somewhere else. e.g. Someone is allocated a work-package to build the installer and will need to see if the required input box, button etc. already exists or needs to be built anew.

Work summary

We have created Excel worksheets for 6 Joomla elements.

• Joomla Web Installer (Ray, Armen, Marco - guest)
• page type “editor” - Content editor (Ray, Christiane)
• page type “manager” - Article manager (Justyna, Stefan)
• page type “manager” - Article Category manager (Justyna, Stefan)
• page type “manager” - News Feed Category manager (Justyna, Stefan)
• page type “control panel” - Control panel (Stefan)

We have defined more precisely the levels of decomposition of Joomla

• 1st level:  the main elements of the system: installer, backend & frontend
• 2nd level: the basic types of pages, interfaces, layouts (in frontend,e.g. blog, list article category) or 'steps' (in installer)
• 3rd level: elements category, e.g.
  • structural elements: page regions, labelling regions, headings, content structure
  • presentation elements: how the content is presented to the user (text, icons, graphics, video, button, cards, tabs) who sees, who cannot see but can hear
  • interaction elements: links, forms, form elements (input text, button etc.)
• 4th level: sets of objects that contribute to a certain functionality e.g. menu, toolbar
• 5th level: functional objects (objects that create functionalities e.g. button, switcher, forms) or information objects (e.g. heading)
• 6th level: function, feature e.g. label, tooltip, links, column headings, sorting, filtering
• 7th column: link to EWP Elementary Work Package)  

We have defined the following terms

• Work packages are small sets of tasks that solve one particular aspect of accessibility. They are designed for programmers, tester, designers, as well as for e.g. trainers, accessibility evangelists, administrators.
• Elementary Work Packages (EWP): elementary tasks, design problems to be solved, tested, implemented  

We have defined the method of documenting the work. A record of the work shall be kept of it:

• Excel sheet "Decomposition of the Joomla from accessibility perspective".
• Task packages saved in Word documents
• List of problems to be solved and further discussions.
• Glossary

We have identified the addressees of the work packages. The addressees of task packages may include

(a) programmers, include members of Implementation & Development subteam

• in the first stage, develop new solutions to the problem or PR that corrects errors
• complement the documentation after implementation with a coding template and examples of good and bad practices

(b) testers (members of the Audit & Testing subteam and the community:

• test at each stage of implementation (i.e. current solutions and corrections)
• describe how the test was performed

(c) members of the Promotion subteam and Help & Documentation subteam

• popularise solutions
• develop the necessary clarifications.

We have set out our plan for the near future

• familiarisation with the results of the work of all members of the JAT
• each member of the team has carried out an analysis - an inventory of one side of the backend or frontend
• work out 3-4 task packages and then develop a template for the package

Sub-team “Implementation & Development”

Implementation & Development sub- team is not official yet, we are in formation and this is first meeting to get thing started.

On 12th May, Andrzej Kasprzyk, Stefan Wajda, Ray Selby, Carlos Camara, Noemi Sanchez found an opportunity to meet with Dmitris Grammatiko, who’s input was very valuable. He agreed with Ray that the main task is to find a way that a flow could be constructed that took the code from GitHub, one time. Then, the relevant piece that makes up a specific work-package can be copy/pasted into CodePen. The code can then be revised, according to the previously documented rules and the URL can be sent directly to the tester, who can see that the implementation is correct. He will either mark it as completed or comment on what still needs to be done, in order for it to be fully accessible. If complete, the developer needs to do nothing more. The work package will be taken over by the documenter, and other team members who may have relevant testing tasks, etc. Otherwise he will make the changes and repeat the process, until it is completed.

The documentation will be gathered together into a wiki that will be made public, so that 3rd party extension developers can follow the process of making their code, also, accessible.

Documentation

We will make documentation on GitHub for UI components, we are aware that we have to do this in such a way to be compliant, for copyright.

We are going to prepare some work packages individually, then we will merge it to a template. After we have made an example of a work package template; we will present instruction by the end of (30th) May, how to prepare a work package.