Third sector organisations work hard to serve their communities. However, many overlook the need to ensure their website content is accessible to all visitors, including disabled people. Websites that are not designed with accessibility in mind can exclude disabled people from accessing information and services.

In this short post, I explore why accessibility is crucial for third sector oranisations, and some steps they can take to ensure their websites are accessible.

What is Web Accessibility?

Web accessibility refers to the practice of designing websites that are accessible to disabled people. For example, people with visual, auditory, motor, or cognitive impairments. Everyone, regardless of their abilities, should be able to access information and services online.

There are laws and guidelines that require websites to be accessible, including The Equality Act 2010, British Standard 8878 Web Accessibility Code of Practice and the Web Content Accessibility Guidelines (WCAG).

Why Accessibility Matters for Third Sector Organisations

Third-sector oranisations have a unique responsibility to ensure their websites are accessible to all users. These organisations often work with marginalised communities, including disabled people so, it’s important that their websites reflect their commitment to equality and inclusivity.

In addition to ethical considerations by ensuring that their content is available to all users, these organisations can expand their impact and connect with people who may not have been able to access their services otherwise.

If their websites are not accessible third sector oranisations leave themselves open to potential legal challenges – if they are percieved to be discrimination against disabled people – under the Equality Act 2010. Lawsuits and negative publicity can harm the reputation and effectiveness of third sector organisations.

Designing an Accessible Website for Third Sector Organisations

Creating an accessible website involves following best practices for website design and using tools and resources that can help ensure accessibility. Some best practices include:

• Creating a logical structure for the website, including headings and subheadings.
• Providing alternative text (alt text) for images, which describes the content of the image for users who cannot see it.
• Using clear and concise language that is easy to understand
• Ensuring that videos are captioned or have transcripts available.
• Providing options for users to increase text size or adjust colors for better readability.

There are also several tools and resources available to help third-sector organisations create accessible websites. Accessibility checkers can scan websites for potential accessibility issues, and WCAG guidelines provide detailed information about best practices for accessibility.

Website accessibility is a crucial aspect of web design for third-sector organisations. By ensuring that their websites are accessible to all users, they can increase their reach, align with their missions, and avoid legal risk.

I specialise in providing accessible website design, website accessibility checks and web accessibility training to the third sector, the public sector and further education. The third sector comprising non-profit-making organisations, non-governmental, charities, voluntary and community groups and further education.

Prior to setting up my digital accessibility business in 2003, I worked for a voluntary sector organisation called, The Wellbeing Initiative. I managed their information service, enabling trainees to complete tasks as part of the SVQ in business administration. They completed their training while running a real information service.

Between 1996 and 2003 I worked as a lecturer at Glasgow Caledonian University teaching research methods and statistics. And at the same time managed a not-for-profit organisation called The Making Connections unit which was one of the first accessibility consultancies in the UK.

If you run a website in the UK, it must be accessible to disabled people, it is a legal requirement under the Equality Act 2010. But how do you know if your website is accessible or not? One way is to commission an accessibility audit by a professional WCAG 2 auditor. Alternatively, you can use one of the many free, or paid automated auditing tools.

So, why would you pay someone to audit your website when you can just use a free accessibility testing tool? In this short article, I explore the strengths and weaknesses of both of these options.

Automated accessibility testing tools – the strengths

WAVE, Lighthouse and axeTools, are some of the automated tools you can use to check for on-page accessibility issues. Their strengths are that they give you a quick overview of potential problems. For example, issues such as low colour contrast, missing form labels, empty headings or images without alternative text attributes. There’s no doubt they are useful, as even professional auditors use an array of such applications as part of their toolset. Speed, low cost and ease of use are ways in which these tools win out. However, they do have their weaknesses.

Weaknesses of automated accessibility testing tools

Automated accessibility tools can’t tell you if your website is accessible to disabled people in practice. I.e., will your site be fully compatible with access tools such as screen readers, screen magnifiers, colour contrast changers and so on? An automated auditing tools is unlikely to tell you anything about design elements that might make your site difficult to use, even if technically accessible.

For example, the location of important information on a page can have an impact on how easy content can be consumed. If all your important information is on the right-hand side of a page – that can easily be missed by a visitor using a screen magnifier. A person using a screen magnifier may only see a very small part of the screen at any one time – and they find it difficult to get overal context for your content. Ideally they prefer the most important content to be top-left on a page. That way they will find it first.

Are you vulnerable to a lawsuit?

An automated tool can find many access issues, but that doesn’t mean you are not at risk of breaking the Equality Act 2010 and finding yourself fighting a lawsuit on the grounds of discrimination against disabled people. For example, an automated tool can check if an image has a text description, but it can’t tell you if the description is accurate or appropriate. Only a human can do that. The guidelines don’t say you have to provide the same content to disabled people as non-disabled people, but it must be equivalent. So, an accurate text alternative is really important for a blind visitor accessing your content using a screen reader.

Advantages and weaknesses of commissioning a manual accessibility audit by a WCAG 2 professional auditor

Principally, the major advantage is that you will be interacting with a real human. Someone you can talk to and discuss your requirements with. As a result, they can tailor their services to your exact needs. You can ask questions, clarify issues and crucially, get help with implementing solutions to any accessibility issues found.

A professional accessible auditor knows the ins and outs of the legal framework within which your organisation must operate. Including whether or not you need to have an accessibility statement on your site and how to write that statement, if you do. Accessibility statements are documents that have a strict, legally defined format.

Auditors are experts on the WCAG 2 guidelines, which are the de facto accessibility guidelines used by most governments, including the UK Government. The WCAG 2 document is a complex, large, jargon packed and highly technical document. It is not very accessible, in the more general sense of the word.

Input from disabled people

When you commission a manual audit, often the team includes disabled people. These are people with first-hand experience of what make a website accessible or inaccessible. And unlike the automated audit, a manual audit is not a tick-box process, it often includes assessing the general usability of your site, and finding problems that are impossible for automated tools to find.

Downsides to a manual accessibility audit

The downsides are that manual audits take longer to complete, anywhere from two days to 10 days, depending on the size and complexity of your website. And they are not free. However, loss of credibility also has a cost if someone decides to complain that your website is not accessible to them.

So those are some of the things to consider when deciding whether to use an automated tool or commission an audit from a professional auditor. Get in touch if you have any questions or would like to chat about your specific accessibility needs.

* If you are a government agency or receive government funding you also have additional requirements under the public sector equality duty, i.e., you must also ‘anticipate the needs’ of your visitors. A professional auditor will know what you have to have on your website to fulfil the requirement.

As the world shifts increasingly online, the ability to access apps, websites, and documents is crucial. That’s why website accessibility tools, often in the form of plug-ins, are more popular than ever. Specific tools are now available to make sites more accessible for people with sight impairments, motor impairments, seizures, hearing impairments, and cognitive disabilities. The promise is, that with the right plug-ins, the internet can be a more egalitarian and accessible place.

This leads us to the question – do disabled people find website accessibility tools useful, or are they more for the company’s benefit? Is this an exercise in ‘checking the boxes’ for social currency and positive press?

Do accessibility tools/plugins always make things more accessible?

It’s worrisome to think about a shiny new website loaded with accessibility features getting in the way of the preferred tools a person already has installed and already work best for their needs. After all, it would certainly defeat the purpose of ‘accessibility’ if your tools make your site less functional for those you’re trying to help!

It’s always important that any tools you add do not change the site’s original coding, which can interfere with your users’ preferred tools. While some businesses take the time to create genuinely accessible site design, others simply add the free tools in the hope that they will act as a sticking plaster for potential accessibility issues. Yes, some of these plug-ins are genuinely useful, such as widgets that allow users to adjust spacing, fonts, font size, colour, and other visual elements.

What if your website was thoughtfully designed in the first place: in a way that recognised accessibility issues, such as removing flashing lights, ensuring the text was readable, and providing alt text for image? If that’s the case, do you need to install accessibility plugins?

Ensure your tools/plugins don’t interfere with your users’ needs

Think about it this way – if a person with vision impairment has their own screen reading tools installed on their computer, your tools or coding could conflict with their software. That’s why your efforts should focus on creating a more accessible design in the first place rather than adding a plug-in to ‘fix’ any perceived problems.

‘Accessibility’ plugins can cause more problems than they fix. For example, there are plugins that can automatically compose alternative text for photos (using artificial intelligence). However, there’s no guarantee that the text will be reliable. Incorrect alternative text can cause embarrassment for you and confusion for your visitors. It’s better to take the time to add appropriate captions in the first place.

And it goes without saying that it’s a good idea to listen to disabled people. Find out about their needs, ask them to test your website, and give you feedback (I’m not assuming you ask people to give their time for free). How can your design better align with their requirements? For example, if you know that blinking can cause seizures for some people with dyslexia – then you won’t add that feature in the first place. The result is that you don’t need to add a plugin that allows visitors to turn it off.

What do you think?

Do some companies have their priorities backward regarding website accessibility tools? Are you a disabled user who has run into problems with coding or had ‘tools’ meant to help actually hinder you? Get in touch if you want to talk about the accessibility issues on your website.

Remember – when in doubt, always ask. Hire a freelance website accessibility specialist to help you audit your site for accessibility and help you make the most appropriate changes. The last thing you want is for your efforts to be viewed as a PR exercise rather than a genuine attempt to assist your users.

A history lesson: where did the website accessibility guidelines come from and what’s in them?

• 1995: The first web accessibility guidelines were compiled by Gregg Vanderheiden shortly after the 1995 Chicago WWW II Conference.
• 1998: University of Wisconsin–Madison compiled the Unified Web Site Accessibility Guidelines.
• 1999: they formed the basis for WCAG 1.0.

WCAG 1.0. were focused on HTML and web pages.

• 14 guidelines.
• 65 checkpoints.
• Each with a priority level: A, AA. AAA.

A Compliance: the guidelines must be satisfied otherwise it will be impossible for one or more groups to access the Web content.

AA Compliance: should be satisfied, otherwise some groups will find it difficult to access the Web content.

AAA Compliance: may be satisfied: to make it easier for some groups to access the Web content.

14 WCAG 1 Guidelines

• Guideline 1: Provide equivalent alternatives to auditory and visual content.
• Guideline 2: Don’t rely on colour alone.
• Guideline 3: Use markup and style sheets, and do so properly.
• Guideline 4: Clarify natural language usage.
• Guideline 5: Create tables that transform gracefully.
• Guideline 6: Ensure that pages featuring new technologies transform gracefully.
• Guideline 7: Ensure user control of time-sensitive content changes.
• Guideline 8: Ensure direct accessibility of embedded user interfaces.
• Guideline 9: Design for device independence.
• Guideline 10: Use interim solutions.
• Guideline 11: Use W3C technologies and guidelines.
• Guideline 12: Provide context and orientation information.
• Guideline 13: Provide clear navigation mechanisms.
• Guideline 14: Ensure that documents are clear and simple.

WCAG 2 – Published 2008

Not just websites, but also PDF, Google Docs, Spreadsheets, e-Books… and other ‘digital assets’.

WCAG 2.1 – Published 2018

• WCAG 2.1 does not deprecate or supersede WCAG 2.0.
• The differences between WCAG 2.0 and 2.1 are mostly related to the use of tablets and mobile devices.
• They are designed to make content more accessible to a wider range of people, including accommodations for blindness and low vision.

WCAG 2.1 Based on 4 Principles

• Perceivable.
• Operable.
• Understandable.
• Robust

What principles?

• Perceivable?
• Operable?
• Understandable?
• Robust?

What do the principles mean?

Perceivable

WCAG speak: information and user interface components must be presentable to users in ways they can perceive.

Jim speak: the site visitor must be able to recognise that the content exists. For example, by being able to see it, hear it or touch it.

Operable

• WCAG speak: user interface components and navigation must be operable.
• Jim speak: the site visitor must be able to navigate around the site and use the features and functions presented.

Understandable

• WCAG speak: information and the operation of user interfaces must be understandable.
• Jim speak: not only should visitors be able to recognise the existence of the content and be able to interact with it, but they must also be able to understand it.

Robust

• WCAG speak: content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
• Jim speak: it must be possible to access the content using everything from a text-only web browser to the latest Firefox browser. And everything in between, including screen readers and all the different brands and versions of browsers now available.

Each Principle Has A Set Of Guidelines

1. Perceivable: the guidelines relate to:

• Text alternatives for non-text content.
• Captions and other alternatives for multimedia.
• Content can be presented in different ways, including by assistive technologies, without losing meaning.

Operable: the guideline Relate To:

• Ensuring functionality is available for keyboard users.
• Giving users enough time to read and use content.
• Avoiding content that causes seizures or physical reactions.
• Help users navigate and find content.
• Making it easier to use inputs other than by keyboard.

Understandable: the guideline Relate To:

• Make text readable and understandable.
• Make content appear and operate in predictable ways.
• Help users avoid and correct mistakes.

Robust: the guideline Relate To:

• Maximising compatibility with current and future user tools.
• For example, by using valid code.

For Each Principle

There are guidelines – these are the basic goals that authors should work toward in order to make content more accessible.

And For Each Guideline

Ther are ‘testable success criteria’.

• Three levels of conformance are defined as: A (lowest), AA, and AAA (highest).
• Techniques and examples are provided for meeting those criteria.

Mobile Platforms

• All ‘success criteria’ apply to mobile platforms as well as desktop platforms.
• However, the techniques sections does not yet fully cover mobile techniques.

Jim Byrne

Automatically generated captions

YouTube generates captions automatically for most videos. This is useful even if you are not using Youtube to serve them; you can download the resulting captions file to use on other video platforms. For example, if I want to share a video on Facebook or Twitter or transcribe an interview for an article.

And if you need to convert the captions file to another format there are plenty of websites that offer the service for free,

There are a couple of downsides:

1. They are not generated instantly.
2. They are never accurate because the captions are generated by machine-learning algorithms.

You will always need to check and edit the text that Youtube generates.

How to add captions to YouTube videos

• Sign in to your YouTube channel and click on the ‘Manage Videos’ button.
• Upload your video and fill in the basic meta-information, e.g. title, description, keywords, and so on.
• Under More Options set your video language. It’s a good idea to change the visibility to private if you don’t want your video to go public without captions or with incomplete captions.
• Publish your video.

You can now wait a few hours or a few days for Youtube to automatically create the captions for your video. Once your video captions are generated and edited for accuracy you are ready to make your videos public.

Manually add or edit captions

However, if you are impatient, you can also add and edit captions manually.

Add captions manually

• When you are logged in select Subtitles from the left-hand menu (you might have to scroll the left-hand menu to find it).
• Click on the video you have just uploaded or any video you want to add captions to.
• If you have not already set the default language select your language from the drop-down menu.
• Click Confirm.

Assuming captions have not already been generated you will be presented with a dialog box with three choices,

• Upload a file i.e., an existing captions file.
• Auto-sync. This allows you to edit existing text or copy and paste a transcript for YouTube to sync.
• Type Manually, i.e., type in the speech in real-time as you watch the video).

I recommend you use the Auto-sync option.

To use Auto-sync – write out a full transcript of your video – ignoring any related time information. Then click the Auto-sync option and paste your text into the form field. Click Submit.

Youtube will then create the timings automatically – syncing your text with the audio of your video.

Writing out a transcript of the video in your favourite word processor is easier than typing the captions into the YouTube form as you watch the video. I’ve done that many times and it’s a taxing and time-consuming activity.

Editing captions

To edit your captions, click the Subtitles link from the left-hand menu and choose the video you would like to edit.

• If you have added captions manually it will say, Edit.
• If you have not added captions manually, the link will say Add.
  If captions have been generated automatically, you will have a link that says, DUPLICATE AND EDIT.
• To add captions manually click the Add link. To edit manually created text click the Edit link, to edit the automated captions click DUPLICATE AND EDIT.

Edit automatically created captions

To edit the automatically added captions click DUPLICATE AND EDIT and a new editable copy will be created.

Then click the Edit link for the copy of the published captions text.

YouTube is not good at adding proper punctuation and capitalisation of words – so be sure to look for those issues.

Download the resulting captions file

To download the captions file click on the three dots to the right of the EDIT AS TEXT link within the captions dialog and choose Download subtitles.

By default, it downloads the captions in .sbv format (it does for me – but check if that’s the case for you). Use a conversion service such as the one provided by Arizona State University to convert the file to .srt.

If you Google for .sbv to .srt conversion you will find several websites that will cover the file for free.

© Jim Byrne 2022

Zoom was created in 2011 but it didn’t take off until its use during the pandemic – when it became the de facto video chat tool. There can be no doubt that it’s a powerful and valuable communication tool, however, it also has some major accessibility issues. In this short article I set out what some of those issues are and suggest ways to get around them – where possible.
For example, Zoom doesn’t always work well with screen reading software.

• Users are not alerted to new chat activity. It can be difficult to copy and paste URLs from the chat. And the audio can cut out if the screen reader user switches between chat and video.
• There are issues with screen sharing. The Share Screen function in Zoom is only screen-reader-accessible to the individual sharing their screen.
• There are issues with closed captioning.
• The Whiteboard function in Zoom is not accessible. Using the whiteboard is equivalent to posting an image to the screen – however, the image does not have a text description.

Chat functionality

If you are going to be using the chat function you can use a ‘chat wrangler’, i.e., a person who monitors the chat, tells the group of new messages, and reads them out. Or you can separate out the chat and use an accessible chat application instead of the one built-in to Zoom.

Any important information, such as links should be sent to participants by email after conclusion of the session.

Accessible chat applications :

• Olark’s chatbox widget – which you can install on your web page.
• Click4Assistance.
• Olark Accessible Live Chat.

Keyboard navigation issues with Zoom desktop application

The Whiteboard function in Zoom is not accessible to screen reader uses – as it is the equivalent to posting an image to the screen – but it is an image without a text description.

If you intend to use the whiteboard – be sure to make the whiteboard content available in an alternative accessible format.

If you are using the whiteboard – ensure you are keeping screen reader users up to speed with what you are doing and what you are writing on the board.

Share screen functionality

The Share Screen function in Zoom is only screen-reader-accessible to the individual sharing their screen. If the session is going to involved screen sharing then seek out an alternative to Zoom for the session. There is a list of the most accessible video chat software at, the Big Hack website.

The Polling tool

The Zoom polling tool also has accessibility issues for presenters and participants with some impairments (as reported on Yale University accessibility page). As with the chat example above, you could look at using a third-party tool instead. For example, Mentimeter have a polling tool; they write about inclusivity in their accessibility statement – which suggests that it’s accessible. However, I’ve never used it, so check it out first.

Survey tools are necessarily the same as online poll tools but they might be worth checking out to see if they suit your purposes. The University Of Washington’s has a review of online survey tools. And I see SurveyMonkey has information about how you can make their surveys accessible – so that may also be worth investigating.

Resources

COCo (the Centre for Community Organizations) – about the accessibility of Zoom
DLF Wiki page for access issues with zoom

Jim Byrne December 2021

PDFs are generally created from source documents; often that is an MS Word document – which has to be made accessible before being exported (or in the Mac version, saved) as a PDF.

In this short article I outline the steps you need to take to ensure your PDFs are accessible after you have gone through the conversion process. The information in this article assumes that you have already read my article on how to create an accessible Word Document (outlined in my ‘Creating Accessible Word Documents’ guide).

A summary: how to create an accessible Word document

In summary to make your Word document accessible you must:

• Use styles to add semantic structure, i.e. to create headings, paragraphs, lists and so on.
• Ensure your images have appropriate alt descriptions.
• Ensure that link text makes sense when read out of context and that you avoid using URLs as link text.
• Remove superfluous spacing.
• Avoid using text boxes and floating images; instead use use ‘inline with text’ for images.
• Ensure that you have good contrast between text and background colours.

Create and format your tables correctly to ensure that they are accessible.

How to create an accessible PDF

Once you have ensured that you Word document is accessible you are ready to convert it to PDF What you are now trying to do is to ensure that all the work you have done is preserved during the conversion process.

Luckily it is easy, as all you have to do is, export the file to PDF and ensure that ‘Document structure tags for accessibility’ has been checked within the export preferences pane. Don’t print to PDF – that will not preserve the work you have done in your Word document.

Once you have exported the file to PDF there are still a few things that you need to do to complete the process. You have to carry these steps out within Adobe Acrobat Pro DC.

• Check that PDF tab order is set to use ‘Use Document Structure’. Show thumbnails, select all thumbnails then right-click (Ctrl click on Mac) and on the resulting menu choose Page Properties.
• Click ‘Tab Order’ tab and check click ‘Use Document Structure’.
• Give the document a title via File / Properties / Description.
• And finally, run the built-in accessibility checker. Via, View/Tools/ Accessibility/Open/Accessibility Check.
• Accessible PDFs are tagged documents

The major difference between an accessible PDF and an inaccessible PDF is that the accessible version will be tagged, i.e. each element of the document will have a tag. In simple terms, that means each element has a text label saying what type of element It is, i.e. is it a paragraph, a heading, an image a bulleted list and so on.

It is these tags that allow accessibility technologies to read and organise the content in ways that make it accessible. For example, a blind person can use a screen reader, such as JAWS to list all of the headings in the document and jump to the section they are interested in – only because the headings in the document are identified as headings – using tags. If there were no tags in the PDF document JAWS would not be able o recognise headings from all of the other text in the document.

Arial is a sans serif typeface, designed in 1982, based on Monotype Grotesque. The font has a similar proportion and weight to Helvetica.

It is a font with a contemporary look. Since 1992 it has shipped with every version of Microsoft Windows, which has helped it become ubiquitous.

It is a favourite of desktop publishers, though less so with designers; who think it inferior to Helvetica. The story goes, that it was designed primarily to avoid having to pay royalties (to Linotype) for the use of Helvetica.

It is rarely recommended for print work (though it is a print font). Helvetica is considered a better-looking, more flexible font.

Arial and accessibility

Arial is recommended by RNIB and other organisations concerned with accessibility. If you search for guidelines for document accessibility they all tend to say, use Arial, with a minimum size of of 14pt.

However, I am not aware of any research that shows Arial to a better font than similar sans serif fonts. I think it’s more likely that it was the sheer ubiquity of this sans-serif font that led to the recommendation.

There are similar contemporary-looking, clean and easy-to-read fonts that would do the job just as well. I.e. Calibri, Century Gothic, Helvetica, Tahoma, and Verdana or Myriad Pro.

Note that all of the above fonts are sans serif. Serif fonts are rarely recommended – as more ornate fonts are considered more difficult to read. On lower resolution computer screens the serifs can be distorted, making the words look blurry.

Slab serif Fonts

Having said that, slab serif Fonts (a type of serif typeface characterized by thick, block-like serifs) such as Rockwell, Clarendon, and Museo Slab are considered easy to read and accessible. They tend to be used for headings rather than body text.

Photo: “Pool of Knowledge” by Ian Muttoo is licensed under CC BY-SA 2.0

As a website designer or an organisation commissioning a website you need to know how the term ‘disabled people’ is defined for the following reasons:

It will have an impact on the approach you take to making your website accessible.
As an organisation you will want to stay on the right side of the law when it comes to making your content and service accessible to ’disabled people’.
Ok, how is the term defined in law?

To paraphrase the UK equality legislation, the term, ’disabled people’ is defined not by the cognitive or physical impairment of the individual but by the physical (or virtual) environment they live in.

For example, if a wheelchair user turns up for a job interview to find that they can’t get in the building because there are steps up to the front door, that’s a problem. The legislation states that it is not the individuals mobility problem that makes them disabled it’s actually the lack of a ramp.

The design of the building and a lack of an alternative access route is preventing them from attending the interview. What needs changed here is not the person but the design of the building or the addition of an alternative way in.

In other words the individual is not expected to suddenly regain the power of their legs – their lack of mobility is not the issue. However, in this the lack of access to the building has put the individual at a disadvantage and that is against the law.

I understand how that works for buildings, what about websites?

The issues are exactly the same on the web. You can’t say that your website is not designed to be accessible to people who are blind or have Dyslexia or people with a hearing impairment.

If you said that you would be breaking the law; because you are implying that accessibility is due to a problem with the the person and not a problem with the website.

So in summary. If you are a website designer, this definition of ‘disabled people’ tells you that it’s your job to create a design that is flexible enough to accommodate the needs of individuals with different impairments.

If you are an organisation commissioning a website, you may be surprised to know that the accessibility of your website is not the responsibility of your website designer.

The UK legislation clearly states that the responsibility for ensuing your website is accessible lies with you, the owner of the site.

So for you the definition of the phrase ‘disabled people’ means you need to be absolutely clear when commissioning your website that it must be accessible to all users.

There are exceptions to this rule in that the any costs incurred and efforts you make are considered reasonable in relation to the resources you have as an organisation.

Jim Byrne

Digital Accessibility Consultant

Do you need your website to be accessible to disabled people? Do you need an accessibility audit of your existing website? I can help. Contact me. Tel: 07810 098 119