[laimas]

Когда видишь такое
form method = "POST" class = "form-registration" id = "formregistering"
не покидает ощущение, что смотришь не на html разметку, а на пример из арифметики 2 + 2 = 4. Смысл в бесполезных пробелах? Так и чешутся руки посоветовать расставить знаки препинания. А required = "1" и required, это в надежде что-то да сработает? )

Наверное же надо определится какие задачи на какую сторону возлагаются. Хотя ежику понятно, что у сервера задача проверять в любом случае будет. Если ваш класс "декоративный", придется переписывать. Но причем тут ini? Это всего лишь файл с определениями значений переменных, а кидать исключения по случаю несоответствия входного значения требуемому вместо разъяснения клиенту в чем он ошибся, это конечно круто и глупо. Вряд ли это так, надо полагать, что метод openValidator возвращает ошибки определенные условиями проверки. А коли может определять источник ошибок и возвращать их, то почему результат работы класса, это банальное count(AbstractValidator::getNameErrors())? Да и вообще, в РНР в отличие от JS пустой массив это false, проверять количество его элементов совсем не обязательно (есть и empty()).

Если класс будет в массив ошибок складывать не просто сообщения, но и указывать их источник, то есть

$errors = [
    'login' => 'Причина ошибки',
    'rules' => 'Причина ошибки', //да и это сервер также должен проверять, иначе странно      
    //.....
];

то можно же и короче написать, например в цикле передавать методу поля, и если массив ошибок не пуст, то то отдавать его как json_encode('error' => $errors); А еще бы лучше, если бы классу отдавать массив полей и проверять что возвращает, либо 0 как Ok, либо массив ошибок. В общем это должно работать и тем таких вообще возникать не должно, ибо в ином случае, это не работа связки клиент-сервер, а полнейший бред.

А уже под этот диалог и должна быть сверстана форма - она должна быть сверстана так, чтобы элементы выводящие ошибки обрабатывались одной для всех операцией, а не для каждого поля свое. Пусть проверкой занимается исключительно браузер, а для старичков проверкой будет заниматься только сервер, при асинхронном обмене это для клиента будет не в тягость. На клиенте будет проверяться только контроль ввода паролей.

:focus::-webkit-input-placeholder {color: transparent}
:focus::-moz-placeholder          {color: transparent}
:focus:-moz-placeholder           {color: transparent}
:focus:-ms-input-placeholder      {color: transparent}

$(function() {
    function showError(err) {
        $.each(err, function(f, e) {
            $('#'+f).text(e)
        })     
    }
    
    $('#formregistering').submit(function(e) {
        e.preventDefault();
        var err = {}, btn = $(this.button_register).prop({disabled : true});  //блокировать отправление формы на время запроса, в success снимать блокировку
        if(this.password.value != this.password_check.value) err.password_check = 'Пароли не совпадают';
        if(Object.keys(err).length) showError(err);
        else {
            //Отправление формы Ajax и данные для отправки, это $(this).serialize(), не надо ручками готовить объект 
            //если в success данных есть объект с ошибками, то передаем его в showError() 
        }
    }).find('input').slice(0, 5).focus(function() { //можно и так .find('input:not(:submit)')..., но нужна и каптча, а где она будет .... 
        $('#'+this.name).empty() //очистить ошибку
        //можно и так
        //document.getElementById(this.name).textContent = '' //очистить ошибку
        //тоже самое и в функции showError() можно так
        //document.getElementById(f).textContent = e
    })  
});

<form method="POST" class="form-registration" id="formregistering">
    <div class="placeinput">
        <label class="place_holder text-registration-form">Разрешено ...</label>
        <input type="text" name="login" pattern="[a-zA-Z\d]{3,24}" class="input-registration form-login" placeholder="Введите логин" required>
        <div id="login" class="error-forms"></div>
    </div>
    <div class="placeinput">
        <label class="place_holder text-registration-form">Разрешено ...</label>
        <input type="password" name="password" pattern="[a-zA-Z\d\-_]{10,24}" class="input-registration" placeholder="Введите пароль" required>
        <div id="password" class="error-forms"></div>
    </div>
    <div class="placeinput">
        <label class="place_holder text-registration-form">Разрешено ...</label>
        <input type="password" name="password_check" pattern="[a-zA-Z\d\-_]{10,24}" class="input-registration" placeholder="Повторите пароль" required>
        <div id="password_check" class="error-forms"></div>
    </div>
    <div class="placeinput">
        <label class="place_holder text-registration-form">Ваш email</label>
        <input type="email" name="email" class="input-registration" placeholder="Введите email" required>
        <div id="email" class="error-forms"></div>
    </div>
    <label class="checkbox-emulate"><input type="checkbox" name="rules" required> Я согласен с политикой конфиденциальности</label>
    <div id="rules" class="error-forms"></div>
    <input type="submit" name="button_register" value="зарегистрироваться" class="button-registration">
</form>

Как будет сверстано в конечном итоге, это уже ваша забота, но соответственно и скрипт должен учитывать верстку. Заметьте, что имя поля второй формы пишется не через дефис, а через нижнее подчеркивание, иначе обратиться к нему так как в скрипте нельзя. Разрешенное для ввода в логин и пароль тоже не отличается логикой, более логично, это - и _ естественней для логина, нежели для пароля, но хозяин барин.

Формат данных диалога клиент-сервер можно либо определить жестко, либо анализировать ответ сервера по заголовкам - если json, значит ошибки, если html, значит успех. Можно исключительно в json, проверяя тип возращенного из json. В общем определяйтесь.
Вообще-то после регистрации успешной пользователя перенаправляют, то есть ошибки - показываем и ждем исправления, либо перенаправление.

Стили для сокрытия подсказки в полях при получении фокуса полем.